At Substantial, our day-to-day focuses on designing and building exceptional software products for clients and their audiences. But we were excited by the recent opportunity to spend two weeks being our own client. Our goal: to learn more about Android and Material Design. With one engagement manager (Will), one designer (Dheyvi), and five developers (Alex, Andy, Kristina, Mark, Olivia), we hunkered down to identify and create an application concept. Although we didn’t get as far as we wanted to, we gained a lot of insights. Below is a bit of Q&A with our team about the experience:
How did you spend the two weeks?
We spent a day and half figuring out what we wanted to build and what would be required to set it up. It resulted in the decision to build a multimedia sharing application (think “Vine collaboration”) that let us explore Android’s MediaRecorder. Then we dove into parallel streams of tech discovery and design; while features were being prototyped, design worked on detailed flows, styles, and assets. We did a quick naming exercise halfway through, which acted like a launch pad in getting to our final name. Our designer was out for the second half of our time, so our developers just continued to work toward the design documents. We got as far as we could in two weeks, but it’s definitely not done. What’s nice about how we worked is that anyone could pick it up and keep running with it now.
What tools did you use? What was your environment?
Dheyvi: For planning, aligning, and tracking the project, we recorded things with Google Docs and Pivotal Tracker. For design, I bounced between Google Docs, Sketch, InVision, InDesign, and Photoshop to create mood boards, wires, comps, flows, app brand and icons, style guide, and prototypes. Design assets were shared with the team in a folder on Google Drive.
Andy: We wanted to learn about the latest version of the Android SDK and build tools, so we focused on SDK 22 and Android Studio. We used JUnit 4, Robolectric, Mockito, and Hamcrest to unit test. All of our code was hosted on GitHub.
In Tweet format or hashtag – what was your favorite part of working with Android and Material Design?
Olivia: #brightcolors #sorryholo
Will: It’s really easy to stand out via good design in the Android ecosystem.
Dheyvi: Material Design documentation makes it super easy to understand and apply. The animations also put feedback above display. #keepingitclean
Mark: Working in a statically typed language for a bit was a nice change of pace.
Andy: Forced design thinking due to static typing in Java. #OODesign
Alex: #unittestingispossible android + robolectric + hardwork = ok unit testing
What was the greatest challenge you faced and how did you overcome it?
Will: Despite having my own particular vision for what the product could be, that wasn’t really the point of the exercise. So, I tried to get out of the way once we were up and running with the design/build process. The point was for us to learn as much about Android and Material Design as possible, so I had to suppress my usual urge to focus on the goal of building the product and jump into the learning process myself.
Mark: The biggest challenge for me personally was probably lack of knowledge about the Android ecosystem in general, and Android unit testing in particular. I overcame it through learning from Olivia and Alex’s past experience, reading a bunch, and just trying stuff. I also found that my experience on other platforms helped inform my research on this one. For example, I suspected there were probably nicer test matchers available than what came set up by default, so it was fairly easy to find them since I knew more or less what I was looking for. If this were my first experience with TDD (test driven development) I’m not sure I would have even known to look for anything.
Alex: The greatest challenge was figuring out how to make forward progress with Material Design. The design spec is very well documented and I assumed that the latest version of Android would include most of the design elements present in the spec. I ended up spending a lot of time trying to figure out how to use the Material Design elements in Android, and after a lot of trial and error, and research, I realized that only a small subset of the design elements are natively present. After accepting this fact, the next challenge was to decide whether I should attempt to build the elements by hand, or use one of the many off-the-shelf libraries and neither approach worked well.
What did you learn in the past two weeks that you plan to use on other projects?
Olivia: I learned how to set up and write tests for an Android application, as well as how to use some libraries that allowed me to be more efficient in writing code for Android.
Kristina: When you’re stepping into a brand new project, in a language and platform you haven’t used before, conventions like TDD (test driven development) can make it easier to digest and get started. There’s some comfort in having a familiar context to start working within.
Dheyvi: For this project, we spent our first days figuring out our app together instead of breaking up and diving into design or code. I also created more detailed documentation on interaction flows and a style guide (something we are wary of because we prefer getting answers through co-location and collaboration). I think both things improved our efficiency as fewer questions arose while we worked and we were all aligned on how to move in the path forward. So, setting up the project together up front and putting a bit more detail in documents are both things worth continuing on other projects to improve efficiency and team dynamic.
What would you do different or the same if you had to start the two weeks all over?
Olivia: I would spend a day going over Android basics rather than responding to individual questions as they came up. This would let everyone start with a better understanding of the differences between developing for Android and other platforms. (Note: Olivia had the most recent experience with the Android platform on our team.)
Will: I’d be more explicit and realistic about what we could achieve in two weeks. We actually got pretty lucky because we landed on an idea that we were all excited about fairly quickly and it was an idea that enabled us to learn a lot (which was the actual goal – the learning), but that could have gone very differently. It was fun to engage in the ideation process, but there’s potential to spend lots of time spinning your wheels. We probably could have gone into it with an idea for a prototype that would enable learning, rather than spend the time deciding what to build.
Andy: One thing I would do differently next time is to put more effort into understanding how to test activities and fragments. Activities and fragments are the primary way to interact with the user and build the UI, so testing them is crucial. This was a source of some frustration during this project. Some of that frustration could have been mitigated, at least in part, with more up front effort to grasp unit testing in the context of Android.
What do you wish you had known about Android and Material Design prior to starting?
Kristina: While there’s a lot of documentation, it can be hard to dig through everything. Android libraries sometimes depend on old libraries that cause conflicts. Material Design hasn’t really been implemented for Android, which is a bummer.
Mark: I think we could have had tests up and running faster if we knew that our desired combo was going to be JUnit + Robolectric + Mockito. I feel like we had some initial uncertainty around whether or not we would want Robotium, or if the default Android tests were going to be adequate, or what.
Alex: I wish I would have known that Material Design is not fully implemented in Android.
Now that you’ve worked a little with Android & Material Design, what’s the one thing you think everyone should know about them?
Olivia: There’s still room for your app to be unique within Material Design.
Dheyvi: Material Design is a quick and easy way to get an app started, but you might need to break a few aesthetic rules to make sure your brand stands out.
Mark: Unit testing is rad and people should do it.
Andy: Beware of documentation: Make sure you are looking at the correct API version when reading documentation. There were some major differences with API 22 and older versions.
Alex: Everyone who is working with the MediaRecorder should understand its limitations and plan accordingly.
There’s a lot more we’d like to share about what we learned and will be writing a couple more posts – so stay tuned.