Mock-Ups Round 1

http://www.openamazing.com/wp-content/uploads/2011/05/Shine-Weather-at-a-Glance-iPhone-640x467.jpg

Shine for iOS is a perfect example of the tenets of user interface design and experience being integrated into data presentation better than many other applications. This delivers a popular experience for they took note of many specific needed lessons.

http://cdn.androidtapp.com/wp-content/uploads/2010/04/The-Weather-Channel-Now.jpg

The Weather Channel app presents too much information to the casual user and in a non clean way. When one dissects what a casual user would want on a weather application a few pieces of info come to mind. Where is the weather report from? What is the current temperature? What is the current weather? What is weather in the future? Reliability of the future forecast. *Maybe* What is the wind?

With those determined pieces of information we can see why the Shine app succeeds and the Weather App fails. The information on where you are should be presented at the top of the screen since all further information derives from it. Since the focus of the app would normally be current weather/temp and then forecast the screen needs to be broken up nicely as such. Having a constant navigation bar on the bottom is the typical method for Android for navigation. It could be used for more power functions and then leaving the main screen for these simple pieces of information of Location, Current Weather, Current Temperature, Upcoming Weather (5 Hr?), Upcoming Temp, Reliability



This initial mockup for the OSWeather (Open Source Weather) shows the reliance upon a single screen that presents this information in the fastest way possible. A picture depicts the weather best over any sort of text while the temperature needs to be a static number that can be focused on the center of the screen. The forecast will lie directly below this and show one large number for a 5 hour forecast in the future. Since we want to keep a similar format, we'll use another picture with a temperature and percentage underneath in order to depict the forecast.



This brings us to this final mock up design for the application. A couple points to note here which give it a very non cohesive feel which will need to be addressed in the actual application. The images are not branded the same which give us a clear disconnect. The font is a plain style. The white background on top as a placeholder does not mesh with the general look of the application background (which will need to be the same).



And after a bit of work on getting consistent color scheme and feel to the application, the final mock-up with the resources intended to be used emerges...

Telling a Story

After a hiatus due to travel, a blogpost that encapsulates the last ~ week of research and work is due. This helps the interested student, researcher, coder, designer, and/or person understand an *amazing* resource for this thought process. Bill Moggridge, designer of the first laptop computer, presents a compelling story of how design should be done and is done via his book Designing Interactions. The link is below:

http://www.designinginteractions.com/bill

Thought one would need to read this book many times, and I cannot pretend that I am a season veteran (or have finished the book, yet) but there are some notes I have already uncovered reading Bill's words. His initial foray into this book starts with personal stories relating his thoughts in a more personal domain to the reader. *This* by itself is designing an interaction in such a way that the domain the user is experiencing it will be most optimal. From my initial findings there are several contextual design lessons that have surfaced.

1. Understand the Guest - This means that when you design any piece of software (or anything) you have to fully immerse yourself, first!, into what the end user wants. I've frequently found myself making software going off of my assumptions, what I want, or other flawed vectors into design. Unless this project will be solely used by you, which in that case means you should only listen to your needs, you'll need to become a chameleon and immerse yourself into the user's world. When will they use it? How will they use it? How much time will they have when using it? What is the environment when they will use it? Mobile? Home? Work? Outside? These are all important questions that need to be answered thoroughly when making anything.

2. Storytelling - Human beings are great visual beings. We crave the ability to visualize events that have occurred. Ever think about how much more powerful a point is to your friend when you put it into a very visual story? Exaggerations always beget the best jokes. These nuanced parts of life are often overlooked but have powerful undertones.

3. Solve a problem - Most everything that is designed for other people needs to address this important, obvious yet often overlooked point. Solve a problem for someone. What is the problem? LinkedIn solved having information for individuals in the business space. Groupon solves having cut rate deals on the fly. Southwest solves having cheap yet professional airfare. Solve a problem; always.

Code will be updated very soon for the process of researching and getting ready for the initial RCOS presentation have left the coding secondary. Since this entire project is on the correct way of building software, I am weary of hopping right into the code.Code base is there and development schedule will be stuck to but the development schedule is such so that coding is more heavy in the last 60% of the project rather than the first 40%.

-Sean

Some Initial Findings - Visual Accuity

The last week and a half has been filled with scouring over examples of interfaces, reading books, finding research papers, looking at business examples and learning Android programming (3.1). I hope by using this blog as an extension of the research + open source code development, anyone who stumbles across this in the future can very quickly grab the knowledge I've spent a lot of time digesting. It is my goal to have someone who is proficient in C/C++ writing shell programs to be able to see this and go 'aha! makes sense' and integrate into their functional process.

The purpose of this post is to accentuate the subtle but important aspect of having a visual component in the application process. Now this seems *very* obvious and I'm sure everyone thinks this but to really nail it down is something that I don't believe many people have done. The purpose of software is to be powerful and easy to use. It should do *exactly* what is purports but theoretically should be able to be done in one click / tap.

Look at the following pictures. Which one appears more fluid?





I'd argue the left one and for a few reasons.










1. Color Differentiation - Human beings are visual creatures with highly tuned eyes to allow differentiation of objects. Apple has taken advantage of that by coalescing the icon look to be stereotypical of the setting title (photos is flower) while making sure to change colors on each one. This allows faster navigation of the menus because you can intuitively track where things are based upon color. The Android menu is black and white though still uses pictures. It appears by lacking color contrast you are actually confusing the user because how natural is it to experience black and white in everyday life? By going against the biological system of the user, systems that are finely tuned for many things, you are hindering the interface.

2. Too much text - The less text the better. The best interface is one where you don't even need to read anything. Games such as Angry Birds, does this incredibly well because they use pictographic means to navigate across menus. Apple vs. Android systems show this again.

3. Layout - This goes with point 2 which is apple makes you drill down into the menu. The idea that you should *only* be shown the screen you are on is an idea I like very much. It helps keep cohesion and prevent confusion.


This Facebook interface shows the thought that must go into the filtering of a tremendous amount of information. This is another part that has come to light after doing a lot of initial research. All systems have data filtering to one degree or another. Having thoughts and interfaces that take advantage for navigation need lots of optimizations. Listed above are a few but yet another is the logical filtering of information. What is the main purpose of the system? What information hierarchically lies above another? How can you segment up the raw data into easy to find ways? Facebook shows some nifty ways on achieving success with an obscene amount of data.



Here you can see the picture shows prominently on the screen with the navigation bar on top filtering to what is most important to the user. Profile or Newsfeed I would argue are the most important.








Which is why the Profile page now looks like this (Newfeed when you login)



Facebook decided the Newsfeed was the most important and rearranged the title navigation bar. Search and Status boxes are centrally focused along with having the auxiliary pieces like messages, requests, etc. shown in icon form on the top navigation panel with the overlay if something new happens. Again, taking advantage (and interesting effect) of the visual system of human being.


Point 2. Know the purpose of the software and your audience. Use location/spatial organization in order to funnel actions towards where it is most needed / desired.





Point 3. Less is more. Looking at arguably the best designed interface in the world (and the current shift from OS X to the App Centric Design) is very intriguing. What was found here is the less text/information to process by the user the more successful the interface is. Here you can have a maximum amount of possible "actions" by the user which helps filter where they will go along with reducing the information processing needed. The dock in the bottom allows for even more reduction because these are persistent no matter where one goes. Think about the infinite combinations of the Android desktop? Each developer can make their own widget? Widgets are a plethora of choices? And you have at least 3 screens to add all these widgets. Much too much information. Apple /just/ added the ability to have notifications in a drop down menu. My bet is because having a user base get acclimated to the system is important plus knowing a maximum amount of actions that should be allowable is needed research. Apple only lets Apple have information pop up into their notification bar and only they can add custom features to the home screen.



This provides good initial foundations for going forward in the research along with having this *core* to the design/functional/development process for the weather app. Code updates, research paper findings, and general good stuff will be continually updated as the summer progresses.

Note on Blog Interface + Initial Research

Even looking at the blog interface chosen (on purpose of course) it becomes clear some of the small nuances that effect the flow to an interface. Rounded edges to the centered text window (containing blog text) removes the harsh edges that portray discontinuity. Moreover, a slightly blurred background adds to realism because of the idea that as humans we do not see the things outside our vision that we do not focus on. Nice touches but important to pinpoint why they are advantageous.

Findings:
- Realism in innovative ways (Blurred background. Rounded Edges)
- Text/Font clear and rounded
- Soft Shadows add to realism

Initial Directions for Generic Research include:

iOS Guidelines: They have the most defined expectations for user experience. Good starting point
iOS Guidelines

Android UI: Good place to see differences between established UI kings and competitors. Allows to see how revisions in new 3.0 operating system UI compares to previous along with Apple's.
Google UI Patterns

Android Tutorial: One persons' view on UI. Depending on findings will allow pitfalls/best practices to be examined.
Blog Opinion

Android UI book: Industry practices
Industry Practices

Exploring the change in Win 7 UI
Win 7 Mango

Wiki the "public" view on UI
Wikipedia


More to come

Thanks to Sean O'Sullivan

And I'd like to thank Sean O'Sullivan for making Rensselaer's Open Source Center (RCOS) possible. Without the generous support of Mr. O'Sullivan, alumni of RPI, there would be no way to have any of the great projects to take place.

Subversion Code

The code for the summer project will be held at the following link:

http://code.google.com/p/rcos-user-interface-research/

Constant code pushes and research updates will take place here. Weekly (hopefully bi-weekly) blog posts will contain information that can't be encapsulated into code.

-Sean

Friday - May 27th Project Start

For the summer of 2011, I propose working on deep academia research revolving around the human compute interaction and interface domain. Because of the increasing importance of interfaces in modern day computers, it is critical to have a resource for understanding where research points towards the greatest advantages. Being a Information Technology / Computer Science student at a very good Institute I still find myself unaware of any sort of standards on the matter. I, also, have found it incredibly hard to find someone / somewhere to get reliable information or source code on the matter. Having thorough examination of where the research is being done will bring to light many common human behavioral trends along with the general ideas that formulate successful interaction with computers.

The proposal is to gather this available information in any form possible. Determine the validity of each research paper based upon the author and other criteria that could deem their opinion/research more valuable. Taking different papers and noting their core direction can give numerous data points for the common underlying laws of interfaces. Having all people save a tremendous amount of time by having easily accessible examples, academic papers and one’s own summary of the noted will make sure that anyone who learns computer science can apply these same techniques to ensure a seamless interaction. Just as understanding engineering is critical to design an effective, powerful algorithm it is also critical to know how to portray this to the user in a powerful way. If the user cannot understand the system, the system has not achieved what is possible.

Developing sample code base that precisely defines examples that are found contrasting this with past thoughts or common mistakes will provide not only a visual feedback mechanism but will elaborate via the code that certain dynamics, such as direct text input, rely on general laws for easy interaction. Having highlighted comments within the source code will give some substance but the bulk of the work will be research plus examples that visually show the lessons learned. This will be worked into the RCOS website so an easy to find link is publicly available, not just on a subversion hosting, letting many people benefit from its existence.

Schedule (Revised):

Following a more academic development route because of the needed information gathering.

May 27-31: Research and find at least 5 scholarly papers.

June 1-14: Research, Read Papers + Current Mock-up and Examples of my interpretation of an interface + common examples of interfaces. Hypotheses where I believe pitfalls are and general consensus on pitfalls.

June 15-30: Research + Determination of avenue for interface mock-ups.

July 1-14: Concentrate on mock-up creation versus research

July 14-30: Evaluate current research found and mock-ups devised. Iterate.

August 1-14: Revise research and refine code base

August 14-30: Deliverable of all goals listed below on Google Code and discuss how to get this information easily available on RCOS website

Goals:

1. To research and discover, at least, 15 prominent papers/book by, at least, 10 various authors revolving around the current paradigms of human computer interaction / interfaces.
2. Accurately reference these authors in an open-source documentation.
3. List and show the evolution of interfaces over the rise of computing (last 50 years)
4. Develop several, 2-3, mock-ups of web apps/ web sites / mobile apps that describe
5. Concisely document via the app interface and internal code, key practices that encapsulate the understanding from the research
6. 5 page write-up specifying the research conclusions compared against initial hypothesis