Utility is your table stake.

Without utility, you don’t have a product worth using.  In addition to utility, there are things like usability and aesthetics.  I’m not going to cover those in detail in this post.  However, both usability and aesthetics can be summed up into one word – desirable.

Imagine driving on a road with the below sign…

…probably not your favorite interchange, right?  What if it was someone’s first time driving in this area?  Or worse, what if the driver was a teenager who recently got their driver’s license?  This would be a nightmare.

Imagine driving on a road like this…

…this road _barely_ has utility, if you ask me.  While you could drive on this road, you would have to slow way down and dodge this rough patch.

While both of these roads have utility (they are both passable), neither road is desirable for most drivers.

This picture of potholes is a good reminder that you can’t construct a road and then forget about it either, you have to maintain it.  Quick-dry patches over a long period of time result in a less-desirable road.  Ultimately, your users will find a different route.

Product engineering is no different.

Ultimately, you have to build a road that people want to drive on.  It has to be desirable!  Meaning, you have to build a product that people _want_ to use.

For example, this is the recently renovated Keystone Ave. here in Carmel, IN…

…this is my preferred road for many reasons.

Just as drivers choose roads for their daily commutes, users choose products for their daily uses.  Make sure you’re building a product that people would find desirable, in addition to your table stakes.

Ask yourself – Is your product desirable?

Well, it looks like Git Extensions grew some sweet new toys that take advantage of Windows 7.

If you haven’t played around with some of the advanced features in Windows 7, I highly recommend it.  The JumpLists are probably my favorite new feature.  There are 2 different JumpLists that I use on a regular basis – in the Start Menu, and on the Taskbar.  They reduce context switching, and allow me to do activities quickly.

Here is a snapshot of using the JumpList in the Start Menu…

…it allows you to jump directly to a recently used repository.  Very handy!

Here is a snapshot of using the JumpList in the taskbar…

…it allows me to commit, pull, and push from the taskbar.  This is extra awesome because now I don’t actually have to pull up Git Extensions.  Instead, I just keep it minimized now, and even _more_ out of the way.

Do any tools you use regularly have some cool/awesome/fun features that integrate with your OS?  If so, what feature and how does it impact how you use the tool?

I wasn’t able to quickly find any documentation on the Java SimpleDateFormat strings by locale…so I did what any Passionate Programmer would do, and I wrote a method to do it for me.

Then, I needed to get this file off of my emulator. To do that, I opened the DDMS perspective, selected my emulator in the Devices tab (emulator-5554), and navigated to data\data\(applicaton name)\files\(file name).

By default, Android apps run solely in a single thread – the UI Thread.  For most applications, this is perfectly fine.  There are, however, some good reasons that your application needs to be multithreaded.  For example -

• lots of data access – reading/writing to a database is slow
• download information from the internet – mobile networks can be spotty, or slow
• sync with other components – for example, performing Bluetooth pairing or communicating with a service

If you want your thread to be able to interact with the UI and still perform operations in the background, then you’ll need to use some Android specific classes.  The simplest form in Android is the Handler.  A Handler allows you to send/queue messages, execute Runnable objects, and even perform some fine grained scheduling.

One of the best uses for a Handler is for displaying progress.  When communicating progress via a dialog, or progress bar, or whatever, it is good to use a Handler because the user can still interact with your UI.  For example, if the user decides they don’t want to wait, they could press the back button.  Or, perhaps the operation you’re doing doesn’t require the user to wait, they can continue to use your app while information gets updated asynchronously.

Thinking of the G+, FB, or TweetDeck apps that try to backfill your stream…if those apps blocked your UI, and made you wait, you’d most likely never use those apps again.  Or worse, you might go as far as leaving negative feedback in the app store!

So, MaTT, how do we do this?

The example below uses a Handler to set the progress on the UI.  So while the Thread is doing some lengthy operation (mProgressStatus = doWork();), the Handler is able to update the UI by calling the Post method, and setting the progress.

The reason you NEED a Handler here, is because you can’t access the UI from the Thread object.  The Android UI toolkit is not threadsafe by default.  If you try to access the View to update it, there is a good chance you’ll get some amazing Null Reference exceptions.

Each Activity only needs one handler, so you can use that Handler for different tasks or for updating multiple UI components.

So, MaTT, when do we use this?

This approach is great for simple, yet long, operations.  You are still able to show progress to your user and you don’t block the UI while it happens.  Using Handlers won’t give you 5 stars in the market, but it can help keep you from getting 1 star.  Handlers are ideal for one-off situations where you need to do something, but don’t want to interrupt the user.  The other beautiful part about using a Handler is, you don’t have to worry about creating some complex messaging architecture that takes a week to develop and test.

If you find yourself putting Handlers all over the place, consider using a more robust solution like AsyncTasks which I will cover in more detail in my next post.

Android Thread Series:

1. Overview
2. Handlers
3. AsyncTasks
4. Services and Messengers
5. Conclusion

Ultimately, users want to have multiple applications running, syncing data, and connecting to the internet.

One solution to meet this demand is to block the UI and potentially display progress.  This can be a problem because users who perceive an application to be slow, sluggish, or non-responsive will give your app poor reviews in the market.  A more ideal solution is to perform long running, slow, or blocking tasks in the background.  The same work is being done, but the UI is snappy, or responsive.  An added benefit is that you won’t end up having one of these gems while trying to get the latest news updates about the NFL Lockout… <sigh/>

Android has many options for performing background tasks.  Specifically, Android gives you the opportunity to define what process your component runs in, control threads, and communicate remotely with components and processes.  Great!  Let’s use this to make awesome applications.  What’s the name of this magical background task thingy?  Well, get ready, because there’s a list…

• Process
• Thread
• Synchronized
• Handler
• Messenger
• AsyncTask
• Service
• BoundServices
• IntentServices

In theory, this is great!  However, there are so many options that it can be overwhelming.  And you can’t just start moving everything to a new thread, because multithreaded applications introduce new challenges, like…

• What about concurrency?  Is that a problem? (That’s a rhetorical question.  Of course concurrency is an issue!)
• Deadlock, livelock, and  starvation (“Oh my!”)
• What do my users expect?  If I do things in the background, does that break the communication loop?
• I’ve heard lifecycle is important, what does this mean?

In a series of posts, I’ll cover the options, explain possible approaches, and make recommendations on when to use which options. I will even put up some sample code to help illustrate my points.  Along the way, I will answer the above questions and more.  After all, you want to be sure that you’re using the right tool for the job, right?

Android Thread Series:

1. Overview
2. Handlers
3. AsyncTasks
4. Services and Messengers
5. Conclusion

What’s the point? The point of this book is to write clearly and concisely, to differentiate yourself, and to better equip yourself with tools for writing persuasively.  Ultimately, this book is designed to help you and your company write winning proposals.

How was it? Good.  I honestly felt that this book was easy to read.  Many times, there is even some humor written into the book.  Two of the best tools that I took away from this book were NOSE (Needs, Outcomes, Solution, Evidence) and Cognitive Webbing.  These tools seemed to help structure my writing and organize my thoughts.

Who should read it? Anyone who wants to be involved in writing proposals.  Anyone who is responsible for writing, reading, or approving proposals.  Anyone who is on a team that is involved with communicating about proposals.  Even if you don’t agree with everything Dr. Sant wrote, it gives us some common language to work from.

I wanted to learn something outside of my comfort zone (not too difficult for an embedded guy to get out of his comfort zone).  I tried to learn Ruby once before, but that was well before I knew how to learn.

Back then, I didn’t really know what being a software engineer was all about.  In the book, Apprenticeship Patterns, there is a group of patterns called “Perpetual Learning“.  An apprentice needs to replace ignorance with concrete skills in order to continue to improve and get better, and ultimately, Walk The Long Road.

One way to replace ignorance is by expanding your bandwidth.  To me, this basically means – learn how to learn more (hence the name of the group of patterns is Perpetual Learning).

When I first tried to learn RoR, I didn’t know how to learn new things.  I didn’t know where to look for manuals and tutorials (short of going to Google and letting them guide me).  Now, a few years later, I feel like I am more resourceful, and my bandwidth is larger; therefore, allowing me to learn new things.

Burke definitely gave me some nudges in the right direction, and over the last couple of days I have gotten completely set up with Ruby and Rails.  I’ve also completely exhausted TryRuby and am actively working through RailsForZombies.  (Which are both pretty fun, I might add…yes, I said fun!)

If you have worked through the TryRuby guide, then you’ll understand the title of this blog.  This style of learning aligns well with many of the Apprenticeship Patterns.  I hope to continue learning, expanding my bandwidth, and practicing.

Today, Mt. Hood was stolen…tomorrow, I will aim a little higher.

It dawned on me this morning that in the past year at work, I’ve worked on an embedded C project, dabbled in C# and .NET, done some LabView work, evaluated a Matlab project, built a prototype in WPF, and touched on multiple mobile platforms.

Wow!  And that’s only the technologies that I’ve worked in, that doesn’t include all the different and new processes I’ve been involved with.

One of our VP’s, Raman, once said that variety is not an option, it’s a requirement at SEP.  I get what he means, now.  I also understand why it’s good for someone to get variety, continue to learn, and continue to do new things.

It is challenging, but exciting all at the same time.  I wouldn’t claim that I’m an expert in any of those areas, but I’m able to be on a team and be productive, and that’s the important part.  There have definitely been some late nights where I’m doing research on my own, but that’s what I have to do in order to keep up with my peers.

Do you get variety in your day to day?  What are some of the challenges of variety?  How do you overcome those challenges?

When I finally took a step back from the problem, I remembered putting together some scenarios and stories during the Jeff Patton training.  I simply wrote a little paragraph about what “Tom the Time Keeper” (I’ve never claimed that creativity was one of my strong qualities, fyi) would do with this new calendar integration; and eventually, I even came up with some ideas about how Tom would configure the calendars.

This story then morphed into a set of use cases.  From these use cases, I could better determine what work actually needed to be done.

My lesson learned here is that if I write a story first, then try to design some new set of features…I can get a much better idea of what it was I needed to implement.  I can immediately see how this could also benefit some of the smaller estimation efforts I’ve taken on as well.  This is definitely an approach I will be repeating!

Jared Spool has reported that only about 10% of the user interface design questions raised by developers over the course of a typical project can be answered by reference to platform-based published guides.

Does this mean that the standards are lacking?

Or does this mean that we can’t categorize UX/UI (User Experience / User Interface) design specific enough, and apply it to a platform?

Or worse, does this mean that the people who are responsible for defining and publishing these guides don’t know their users or know how their users actually use said platforms?

These are just a few of the questions that keep running through my head as I continue to explore usability and UX/UI design.  Hopefully I can find answers to some of these questions in the near future.

___

Currently reading:  “Software For Use – A Practical Guide to the Models and Methods of Usage-Centered Design”