Android ICS Library for Axure Prototyping
Android ICS Library for Axure is based on GUI elements provided by Android and Techie Talkx. It is optimized for 480 x 800 px screen resolution, which is sufficient for developing the prototype and presenting the design.
Following the huge response for the Android library developed for earlier version of Android, I have put together a library of UI elements for Ice Cream Sandwich. For installation instruction, refer here.
I am moving this blog to my personal hosted site. It will be available for download from my site. Kindly bear with the re-direction, once you click the download link above.
Android Library for Axure Prototyping
Based on the Classic Android PSD vector files by webdesignshock, I have developed the Android Axure library (.rplib) file. You may use this for your prototyping exercise to develop any Android applications. Download the file and save it in your computer and follow the instruction below to start using the stencil.
iPhone App Site – Design Trends and UX Patterns
The iStore has a directory of iPhone and iPod applications. But outside the iStore, the application’s dedicated website is an important selling point. To drive the traffic to iStore a well designed site is a necessity. These application sites follow a set of style guide. The target audience for the website are Mac, iPhone and iPad users. The website will appeal to them, if and only if it renders user experience similar to Apple products. They must be clean, uncluttered, simple, minimalistic yet rich and straight forward. Here are a few of the design trends that are followed in an iStore application’s website.
Simple Navigation
The navigation is usually by the top menu. The information architecture is minimalist and the navigation menu has very few items in it. The typography in the menu is usually a sans font with a large typeface. Breadcrumbs are not present, because the app sites have a maximum of 4-5 pages. Many of them are happy with a single page as long as they convey the message. Bottom Navigation is also not a necessity for app sites. The footer is predominantly used to display copyright information.
Rich Images
The app sites generally have an image of iPhone with the application screenshot in it. The images used in the sites are life-size and rich in quality. Some sites have animated movies running in the life-size iPhone image. Invariably all the app site offer screenshots of the application under various use cases. To display the screenshots, lighbox style is preferred. Some sites also provide screenshots in a lighbox window with an iPhone frame. These sites are purposefully built to serve as an eye candy and their target audience are expected to have a high-speed internet connection with a high-resolution monitor.
Fold
The content is concentrated within the fold. The user isn’t going to spend too much time on the site browsing for extra information. During the short stay, the user will glance at the key features and head to the iStore, if interested. So its logical to give all the vital data to the user at the first glance. But some users may want to read the application specifications. So the extra details are pushed below the fold.
Tags and Badges
Link to app store, Compatibility info, price and offers are the key links in a iPhone app site. These links are represented as images. Some sites follow the apple standards for the images, but many sites add their creativity to these images. These images are the eye-catchers in the site and a key decision-making aid for the user.
Social Networks
Social networks are no more a luxury. It’s a necessity and its need is exponentially on the rise by every minute. Application developers post details like upcoming releases, version updates, patches, tips, offers etc in social network sites to lure users to use/buy their application. Most of the application thrive on word-of-(social)mouth publicity and its important to have links to the custom social network page from the app site. These links are found as text or image links anywhere in the site. Some sites have it in main body or in the footer.
a few iPhone app sites for design inspiration
'Password field unmasking' as an anti-pattern
When I say anti-pattern, it points to the UX patterns which isn’t in the conventional usage, but it could solve a few UX problems and may also introduce new problems. It’s got to be subjectively judged and measured by its impact on the user experience.
The problem:
I am a member of over 50 social networking sites (5 active, 2 hyperactive), member of some 50 forums, and have signed up with over 500 sites. I have to remember username and passwords for these sites. Adding to my load are my online banking accounts, windows login, folder protector softwares, encrypted zip files and many more. Everytime I type in the password to access any of these, I am not sure about what I am typing. I have to look at the keyboard, rather than the screen to make sure I am typing in the right characters. Most of the time am not sure if the particular combination is the right password. There is always uncertainty until the screen grants access. The reason being that the password field is masked. To overcome this difficulty and uncertainty, we tend to use simpler passwords and make it a unified combo of username and password across all websites. Thus acting like a sitting duck for the hackers out there.
The solution:
Jakob Nielson suggests that the password field must be unmasked. He further justifies that most of the time there is nobody looking over your shoulders. Also a trained person can see your key-strokes to get your password.
Well, most of the time there are people around me and there is a fair chance that they are peeking into my screen. It’s not a globally valid assumption to make. One is a 100 person could be trained to see keystrokes, but almost everyone can read the typed password if it’s not masked. This assumption fails as well.
The suggested solution is to mask the password field by default and leave the decision to the user to choose between unmasking it or not doing so.
Example 1:
Just like a check box to save the password and remember the user’s session, another check-box can be added to mask or unmask the password field. If user unchecks the check-box, the password field is unmasked and the users can see what they are typing in it.
By default the password field is left masked. It’s the user’s choice to unmask it. A practical example of this pattern is the winrar application.
Example 2:
Saving password in the cache memory and also revealing the password field could be a security issue. The user’s trust is very important in the user experience. To gain the user’s trust we can sacrifice one of the 2 features. The weakest link is the save password field. If the user wants to save password, they can always use the browser’s inbuilt feature to save password and save the session in cache. So we get rid of the ‘Save Session’ feature and present only the mask/unmask password field feature.
Example 3:
This is a little more élite method of tackling the problem. A combination of use-cases are employed to design a pattern. If the user selects ‘Home computer’, we assume that the user is in a private environment and they can enjoy an unmasked password field and also saves their login details for further sessions. If the user selects ‘public computer’, its assumed that the user’s privacy is at stake and the password is masked and not stored in the cache. But this pattern calls for a tool tip. The user has to be informed about the consequences of his choice. The system must speaks in user’s language to inform what’s happening within it and the results of the user’s choices.
In all the examples, its important to gain the trust of the user. By default the password field is masked. The user can continue using the system without having to configure it further. The choice is left to the user and they are given the freedom to decide how their login page acts and interacts.
So, how would you like your log in fields?
Giri's Blog 