Time flies.

I haven't written in a while. Not a line on this blog, not a line for govt. That wasn't fun.

Things have been a bit busy lately, which is probably more of an excuse than anything. It's disappointing, though, because I was originally aiming for a September release of version 1.0. I've essentially ruled out any possibility of that happening.

When I was spending more time on govt, I took many opportunities to fill peoples' ears about the project. It was nice to hear such positive feedback for the concept. While talking to friends and colleagues, I received small pieces of validation that this application could help fill a void in the citizen's toolbox. As a result, the application will continue to be developed with a "legislator -> legislation" mindset, instead of the "legislation -> ???" mindset of existing applications.

Tonight, I pushed a non-negligible refactor of some state management that was no good. Also tweaked a few other things that had annoyed me as I idly played with whatever early version was on my phone. Working on govt tonight reenvigorated me, so expect more frequent updates as time goes on.

I can't wait to release something that reduces the friction in learning about your legislators.

How govt is going.

Building something while having a million other things to do in front of you is difficult. This is especially true when the almighty paycheck isn't luring you along. After a flurry of blog posts that talked about what I was going to do, I finally got started doing it. Soon thereafter a convenient set of reasons to defer working on govt appeared before me, and I gravitated before them. Over the past week, I have slowly worked toward getting into a rhythm with this project.

Tonight, I pushed a non-negligible amount of code to the repository. As it stands, govt has a simple ZIP-code based search for legislators, stores legislator info to disk when a search is successful, and displays a minimal piece of information about each legislator in a (terribly ugly and bad) list.

In a way, I am unhappy with the amount of work that has been completed, but at the same time these listed features do not tell the whole story of what's been done. I wrote a database manager, multiple utility classes to manage Fragments, updated Fragments to match modern Android development patterns, and more. Everything that has been completed required thought and consideration, and that is the point of this whole project for me – to think about something while I build it.

Aside from implementing new features, a major set of hurdles will include each step of UI design. Colors, assets (images, etc), interactions, animations, and more will need to be considered if I ever want to release a polished, quality application.

Anyway, I just wanted to assure my ever-anxious blog-readers that progress has been slow and steady, but I am hopeful to speed up soon. Have questions about the code? Send me a note and I can respond or even do a blogpost about the technical decisions I've made thus far.

The repo...it lives!

https://github.com/kevc/govt

For those of you so inclined, you can follow the govt repository at the link above.

This weekend was somewhat productive for the project. I got some foundational things in place, including the choice to use Retrofit for network requests. I am extremely impressed with the library. It plays so well with GSON that it feels...a little bit like magic.

Look at the README for the one "gotcha" related to the API key, if you're looking to play with the app as it is developed. There probably wasn't a tremendous need to be so careful with this API key, but it seems like a good practice to get into the habit of.

The work continues!

Kevin

Google IO: Some thoughts

note: I have been coding govt, but haven't come across any interesting problems or choices to write about. I'll get the code up onto Github in the near future, so you can at least check out the progress there.

Wednesday and Thursday of this past week were filled with big news from Google IO. IO is Google's annual developer conference.

Each year, the keynote presentation serves as a "state-of-the-platform" for Android (and other things I care less about); this year was no exception. During the 2.5 hour(!) presentation, developers were shown the future of the Android platform. There is plenty to be excited about.

The most relevant thing to come out of Google IO for me and govt was the outing of Material Design. With Material Design comes the most significant update to the Android style guidelines since Holo was released alongside 4.0 (Ice Cream Sandwich).

In the design specifications for Material, Google has gone far beyond creating a new design paradigm for Android. They go as far as to specify specific sizes for common UI elements. As a developer making his first foray into the worrisome world of design, specificity eases the creative and cognitive burdens. I have a unique opportunity while developing govt as a brand new app to employ these specifications early on. Hopefully, when L goes out to world, govt will be a slick, new, well-designed application because of my adherence to the new Android design landscape.

A few other thoughts on IO:

  • RecyclerView and CardView, two new libraries in Android L, will be very useful to developers. In different ways, they make performance and design more of a default than a choice, which should force more developers to adhere to system design principles (and run more smoothly).

  • Project Volta (the JobScheduler API) should be used by developers to help with battery life. However, from the way it was described in the Project Volta talk at IO, it seems to have limited use cases, and relies on developers to actually care about users' battery life. I guess that as long as Google applications utilize it, that should be a decent enough bump.

  • Releasing a developer preview for L is a smart move by Google. I've appreciated that some of the new things I'm interested in are in the support library, but until things like the android:elevation View attribute are made backwards compatible, it isn't too much fun to play with. This holds especially true for govt, which will continue targeting API 19 for the meantime.

  • Did I mention that I love material design?

govt: Architecture and Motivations

da vinci style wireframes

I am about to start putting time into the actual development of govt. As a result, I would like to spew out a series of technical plans that I have assembled thus far.

General architecture

govt will be a single-Activity application.

An Activity, at a high level, is commonly the encapsulating class for a "screen"'s functionality in an Android application. More and more developers are sticking with one Activity.

Why a single Activity, then? One of the primary goals for govt is to have a simple tool for tracking the federal legislators who represent you. Congress, the most notable existing application in this space, is far too complicated. As described in the previous post, part of this is caused by grouped interactions being spread too far apart. In govt, is a single Activity going to do much to prevent this? No. Might it simply help my mindset while designing it? Probably.

Fun with Fragments

If the application is going to only have a single Activity, more Fragments will be utilized in order to organize and manipulate Views and interactions. To development govt in a sane way, I will have to tame them, as others have before me.

Fragments are commonly considered a flawed implementation:

Still, they remain a crucial part of Android development. Having dynamic, interesting user interfaces would be much more difficult without them, though there are some tools to make them play together more nicely (e.g. a serial bus).

Known foundational requirements

A state machine will be implemented early on in order to manage the Views and supporting Fragments of the main Activity.

I will likely implement the database with JSON, stored on disk and loaded into memory as need-be. This is the implementation I am most familiar with. Based upon the potential data sources that I will employ, this seems like a reasonable solution.

Libraries

For HTTP requests, OkHttp seems like the way to go. All the cool kids are using it, so why not?

As I said, my data sources will reply in JSON format, and I'll store data that way, too. For parsing data streams, I think I'll try out GSON, with Jackson as a backup. At the end of last year, a former colleague wrote that Jackson was 1.5-2.0x faster than GSON. Still there are some interesting features to GSON that make me think it is worth checking out.

I am sure that I will implement other libraries as particular challenges arise. For now, there's no point in solving problems that are not yet in front of me.

Wrap up

Now, it is time to shut up and code. Developer friends, I would love your feedback on any of the above. None of it is particularly novel, but perhaps some of your experiences will steer me in a better direction. Thanks!

A Brief Heuristic Evaluation of Existing Applications

tl;dr - Of the three applications I looked at, only one is of any real value to users. I found issues relating to efficiency and UI mappings. I aim to learn from these issues in my own project.

Intro

Just a 'heads up' - I'll be referring to this project by a codename henceforth: "govt"

Three Android applications were readily available when I searched for words on Google Play, such as: "Congress," "Government," "Politicians." Briefly evaluating each has created a list of issues that will (hopefully) be avoided while developing govt.

Heuristic evaluations

What are heuristics?

Jakob Nielsen's revised list of heuristics are commonly referred to by computer and technology usability experts. He released this finalized list in 1994:

Heuristic evaluation - Nielsen's Heuristics

Okay, but how do we use them?

By examining software for these criteria as changes are made, teams can identify potential issues. After identifying, they can rate each issue by severity, and proceed to remedy them.

Fine, but what does this have to do with govt?

While heuristic evaluation is commonly used for a team's own project, I have decided that applying these principles to existing applications will help steer early design and feature decisions.

Evaluations

Contact Congress

Contact Congress is a simple application, which was released in early 2012. It simply returns a list of politicians for a given ZIP code, and provides contact information when you select one. With its limited functionality in mind, here is some specific commentary.

Specific concerns based upon heuristics:

Flexibility and efficiency of use:

  • If the app is force-killed, you always restart at the first step, which is entering your desired ZIP code.

  • Selecting a senator or representative's address takes you to Google Maps, which is outside of the application.

  • Utilitarian to a fault - no information outside of how to contact a congressperson.

Aesthetic:

Error handling/Preventing errors:

  • If you enter an invalid ZIP code, Contact Congress presents you with a lovely Toast reading "JSONException," which means nothing to the average human.

Congress 112

Congress 112 is a similarily utilitarian application. It provides a set of static data related to the 112th Congress, which ended on January 3, 2013.

Specific concerns based upon Nielsen's heuristics:

Flexibility and efficiency of use:

gross search

This search screen is..not so good. Am I searching for a person? A committee? A person who serves on a committee? What if I know the congressperson's name, but not their state?

boehner

There are many things to take issue with, but I am most concerned with the star that you see in the image above. It is a toggleable star, but I cannot figure out what it does. Perhaps it is the remnant of some planned, incomplete feature, but all it did was confuse me.

Aesthetic:

The header does not match Android style guidelines, and never did. There is a lot of white space, and does nothing to engage the user with his representatives!

Congress

Congress is a pretty good app. I found issues, but none of them are as serious as in the previous two evaluations' findings. As a result, I was able to dig a bit deeper.

Aesthetic:

  • Dark
  • The first screen you see is very "busy" with different UI components being encapsulated in varying rectangles.

dawg i heard you like rectangles

  • Other UI components are equally "busy."

Shortcuts/Consistency (with other applications)

what do stars even do

As in Congress 112, the "star" (favoriting?) concept is nebulous. The strange thing is that this application has push notifications as an option, so it would make sense for favoriting Nancy Pelosi to be the action that subscribes me to her push notifications.

Recognition vs. recall:

On the topic of favoriting, doing so adds a politician or piece of legislation to its respective list of saved things. These lists are buried under the main screen of the application. If the user wants to look at the things they have deemed important, that have to recall where to go in the application to retrieve that information.

Flexibility and efficiency:

  • User location is not cached - it is pulled from the device every time the user does a location-related action, regardless of the time in between.

  • Congress is optimized for interactions with pieces of legislation. Upcoming legislation is what you first see when you open the application.

  • Subscribing to push notifications is a 4 tap process at minimum. (ex: Open the list of starred legislation, select legislation, go to its 'Activity' tab, click to subscribe to its notifications)

Conclusion

The first two applications, Contact Congress and Congress 112, are clearly incomplete in most regards. Had there been more applications to evaluate, I would not have even written about them.

Congress ended up being an insightful application due to its polish and how many features it had. My biggest issues with it are efficiency of use, how UI maps to functionality, and overall design.

With these things in mind, I will try to avoid other applications' issues while developing govt.

The next post will actually have to do with code. I promise.