The user interface plays one of the most important roles in determining how successfully you can attract and retain the users by making the UI easy to use, efficient and enjoyable. With decision making being increasingly influenced by the online medium, it’s scope is extended to mobile internet. So, it is required to enhance the user experience by developing user friendly interfaces for the apps on the go.

We all are well aware of what all features will be available on the mobile version of a product at hand.  But we are usually not sure about how to arrange them on screen(s), or decide on what framework controls to use to optimize the full potential of a particular product feature. At the end, the most important thing that must not be lost in the process is the simplicity, elegance and the vision, which invariably determines the success or failure of the application i.e. the application rank  in the market(read: popularity).

A good user experience is critical to any application, more so for mobile applications. A good UI will lead to better quality and user experience, eventually translating to popularity and profits. In such a scenario where the users are of utmost consideration in the design and planning of your application, a clean user friendly, simple and yet an innovative UI might just turn a whole lot of users to your application.  Doesn’t it sound appealing as to how something as simple as the aesthetics of an application can do?

Now, this is what we call as “Need of the hour”-But here comes the problem, does anyone know – what is a good UI? How should it look? What should it do? What should it not do, not contain!!!

In such a scenario where you know the problem but not the apt solution, it is always good to have a quick research on how others  got it right.  Abstraction of the problem statement and its respective solution when accepted by a community becomes a pattern. Earlier we had Design patterns for solving design problems of application architecture. “Evolution happened in UI” and now we have a similar set of patterns for the UI. Patterns have emerged as a natural by-product of the design process. Like Software Design Patterns, they too provide a solution to a common/recurring problem. Developing a good and an effective UI requires usage and understanding of these Design Patterns. The best of applications, , are focusing on the use of these design patterns including Twitter Apps, Facebook apps etc.

In this article I shall mainly be discussing these design patterns along with their applications and advantages in use for Android applications and in subsequent ones we shall have a look on how to go about actually creating them.

Dashboard

It has been used in applications even before it was officially introduced as a design pattern. For example, Facebook application has been providing a dashboard of its key functions before it was officially recognized as a design pattern. The Dashboard can be used in apps to highlight the key features of the application. In essence, it is an introduction to the application.  It can be used to reveal new content and capabilities to the user. The dashboard typically occupies the full screen to ensure that it stays out of the way, i.e. the user’s attention is not diverted to any other aspect of the screen/app. The Dashboard may be organized as:

• Accounts
• Features
• Categories

The secondary functionality may be reserved for the Menu options. Thus by making the most common/important operations visible, it ensures that the right things are made visible to the user.

The Good

• Highlight key features to user
• Provide one stop access to all the major functions
• Draw user attention to new capabilities or features introduced
• Easy navigation around the app.

The Bad

• All features cannot be represented on the dashboard
• Some lesser known features not represented, may not get the desired user attention
• Some represented features may not actually interest user, leading to loss in popularity.

Quick Actions

Quick Actions are basically actions/functions in a popup bar that are triggered by specific visual elements/buttons/items on the screen. They have minimal disruptive influences on the screen context. Quick actions ensure that the screen is not cluttered too much with icons and buttons, and at the same time these options are available to the user only when required. They are very straightforward, can be fast and fun to use. Only the most important and obvious options must be presented in the quick action view. When Items have competing internal options, quick items are typically used. In case of contexts that can/may have multiple selections, quick actions must not be used.

The Good

• Uncluttered screen, free of too many icons and buttons
• Minimal disruptive influence on the screen
• Ensures that key functions can be present when needed
• All operations/functions common to multiple items on a given screen can be placed in quick action bars.

The Bad

• It cannot be used if context allows multiple options to be selected at once
• Operations in the quick action bar are specific to one activity only.

The Good

• Uncluttered screen, free of too many icons
• Easy access to key features at all times
• Easy navigation
• Indicates current location/state of the app.

The Bad

• It is always present on top of the screen, taking up valuable space
• It cannot include all functions of the application, jus t the important ones
• Too many options (>5) in the action bar might make it clunky and heavy.

Thus ,we can summarize that the design patterns is the need of the hour which  will go a long way in providing a unified and consistent methodology for developing UI’s that will create a lasting impression on the users.

Keeping these fundamental points in mind while designing any user interface, you can get a kick start to your dream to develop the most user friendly interface.  But what about the design patters for Dashboards, Quick Actions and Action Bar?  I am looking forward to soon share these design patterns. So stay connected to have an interactive information sharing.

For more information, you may want to refer to Google’s session on Android UI Design Patterns

Pradeep Sharma– Technical Lead – Mobile CoE

The speed with which mobile technology is evolving is beyond remarkable. So much, that you may in fact, be viewing this post on your mobile. Gone are the days when you would have a mobile phone solely for the purpose of connecting with your friends & family. Now, you can connect with 300 million+ users on Facebook, listen to the latest music from Last.fm, view videos on YouTube etc. all using your ‘handheld’ device. The list of can-do’s is endless. What goes on behind the scenes is the collaboration of developer minds, striving to stretch technology, constantly redefining benchmarks to create services & applications that make life a whole lot easier.

While the success of social networking is undeniable, lifestyle & Location Based Services (LBS) have helped users to simplify their needs & achieve them; locally & globally. However, the process of satisfying user needs in a constantly changing environment requires a thoughtful understanding & analysis of the changing trends which has been successfully catered to. There is no doubt that there exists a challenge of providing quality applications to a variable audience with innumerable preferences. We have accepted this challenge, acknowledged the pros & cons & delved into bringing out the best solutions.

The iPhone is known to deliver ‘eye candy’ experience with its UI, having the user to touch & pinch to use applications. Having said that, many applications fail to utilize the potential of the iPhone, unable to handle development challenges. Given below is a little insight into some of these challenges.

Developer’s Eye View:

• The iPhone runs only one foreground application at a time, so launching any other application requires terminating the currently running app.
• Responding to interruptions like incoming calls, messages etc. is important because if the user decides to take a call or reply to an SMS message, the system proceeds to terminate the application.
• Low-memory warnings are critical. If not enough memory is released – perhaps because the application is leaking or still consuming too much memory – the system may terminate the application.
• Being a touch driven device, the controls of the application need to be placed with some thought.
• The iPhone screen is precious as it is the component with which users interact. An application with a crowded screen may deviate the user’s attention much like in a real life market place.
• An applications UI view differs when the iPhone is held in portrait or landscape mode. Tap’s drags, and swipes are simple gestures, typically involving only a single touch. Handling a touch event consisting of two or more touches is a more complicated affair. In addition, the iPhone generates motion events when users move the device in a certain way, such as shaking it. It is necessary to prevent the application from responding in an unexpected (and unwanted) manner in response to such events

Now let’s take a look at how one can avoid getting into the possible sticky situations given above:

• It is imperative that an application should terminate as usual, saving any needed contextual information to return the user to the same place (if required) in the application upon next launch (or re-launch).
• Adhering to Apple’s Human Interface Guidelines saves a lot of confusion & gives well designed interfaces.
• Handling events, implementing event cancellation etc. correctly, prevents the app from being left in an inconsistent state.

These & many more underlying intricacies can very well determine the chances of an app being realized. Adapting to this one button device, we have delivered attractive, feature rich applications that meet App Store standards & have satisfied users looking to be part of changing lifestyle trends.

-Anup D’souza

xoriant

What is Flex?

Flex is a way to make SWF files!
At the heart of Flex is the ability to create SWF files that run in Adobe Flash Player. Distill all the features down and it is a development paradigm that compiles to SWF. It really is that simple, but we often make the definition much harder. Just like Flash can create SWF files, so can Flex, but the way you develop it is completely different.

Flex is for developers.

Flex was not built for animators, writers, accountants; it was written for software developers and the paradigm matches the development methodology you already know. If you know Java, C, C++, C#, Delphi, VB, PHP, ColdFusion, Python, Ruby, you can learn Flex with little effort. The goal when Flex was created was to make a development paradigm that developers could learn easily matching the methodology they already know, yet create SWF files for Flash Player (and now AIR). Flex has classes, components, a compiler, a debugger, class libraries, and uses XML (MXML) for declarative markup of components. The ActionScript programming language is based on ECMAScript 4 (the language standard behind JavaScript) and has full support for the ECMA XML scripting standard, E4X. It also has most of the UI components that you already use (like button, list, datagrid, combobox, and tree) but it also supports containers like HBox, VBox, TabNavigator, TitleWindow and many others. If you have written software before, you can learn Flex easily. But better still, Flex is compatible with all HTTP servers, version control systems, and any server side programming language, so the knowledge you have of servlets, php, ASP.net, or JSP is really handy. Flex just lets you program the client side in a paradigm you already know and understand.

Flex is for making applications…

Flex was built for making rich client side application behavior. It wasn’t built for making web pages, banner ads, or server side logic. It was built for creating client-side applications that run over the Internet talking to remote servers. Flex has been used to make some really great apps like Buzzword (Document Editor like Microsoft Word but in the web) or Picnik (Photo Editor/Manager for touching up your best snapshots) or SlideRocket (Presentation software like Apple Keynote but in the web) or Oracle Sales Prospector (An enterprise ERP application. Yes Oracle uses Adobe Flex! ) or many other applications you can see at Flex.org. The real key is that all these examples provide an application experience just like desktop software.

…that run on the web (Adobe Flash Player)…

Flash Player 9 is installed on more than 95% of computers that use the Internet and has been installed more than 3,500,000,000 times at a rate of over 10,000,000 times per day. When you develop software, you want it to run compatibly in as many places as possible. Adobe Flash Player provides a solid foundation to build these experiences without the need to install or update anything on the end user’s computer. If you were running a store you would want that store to be available to as many customers as possible and choosing Flash Player allows you to provide a great experience (rich) to 95% of the web (reach). Make sure you look at the reach of the technology you select. If you choose something not widely installed or incompatible, you are simply turning away customers and business.

…on the desktop (Adobe AIR)…

Adobe AIR is a new runtime in development by Adobe and we are very close to releasing Adobe AIR 1.0. AIR allows you to write desktop software that runs on 3 operating systems (MAC, WIN, LINUX) with the same file. This allows your application to be a true desktop application rather then just a website and allows you to do much more than the web allows today. AIR applications are real native desktop applications and provide APIs for writing files, drag-drop, system notifications, network detection, and more. AIR empowers developers to write desktop software that leverages the Internet.

…on mobile devices.

Adobe is working to enable Flex to build applications for mobile platforms and support a wide range of devices. Just as Flex can be used to write a web based application or desktop application, it can be used to write software for mobile devices. The fact is that devices are becoming ever more powerful and more plentiful. It is just a matter of time before we enable developers to leverage Flex to deliver mobile applications on Flash Lite or AIR on mobile.

In summary, Flex is a development paradigm that allows you to write software for the web and desktop that many people can use compatibly today. It leverages the tools, servers, and development models that you already know and allows you to write the next generation of software compatibly. At Adobe we are working around the clock to make this ecosystem of software better and provide you with the best tools and platforms to make your projects a success.

I encourage you to take a fresh look at Adobe Flex and discover the opportunity in learning a new language and ecosystem. Developers around the world are embracing it to create all sorts of new applications and I think you should jump in too.

If you are looking forward to learn Flex then here are some useful links

Adobe Component Explorer:

Describes various components available in Flex.

Adobe Style Explorer:

Helps defining styles for your Flex application.

Handling XML Data:

Tricks and techniques of using XML data in Flex.

Its fun to play around and learn Flex. Try it…you will definitely enjoy it

by Saagar Shetty

admin

Now for the name…

With apologies to the people who make the cleanser and the detergent, legend has it that the original Ajax was the second most powerful of the Greek warriors at Troy. Even though he had some issues, his strength and skill in battle were second only to Achilles. In naming the technology Ajax, Jesse James Garrett gave the technology both Ajax’s strengths and issues… thus the name “AJAX”

Here are some reasons why AJAX is disruptive in the way people use the Web.

Why Ajax rocks

AJAX has two huge benefits:

1. Speed and invisibility makes for a very slick user experience.
2. The smaller server resources footprint helps server scalability.

I’ll explain these. If you post using AJAX, only the data (or parameters) that the server function requires is posted. In a login scenario, only the username and password strings (100 bytes maybe) are sent to the server and only a boolean value (1 byte) is returned. This means that only 101 bytes (excluding network handshaking traffic) is sent & received. If we were to create the same functionality using ASP.NET, all the state data is pushed to a server and the whole page is returned. Should the page use 20Kb of traffic, AJAX will save nearly 99.5% of this.

Further more, when using AJAX your web server and or db server (or whatever your config is) does not have to do any processing other than running the called function and returning the return value. No page load events, no xsl transform etc. This can have a huge impact in an enterprise environment.

When should I use it?

• On-the-Fly Form Data Validation
• Auto completion
• Master Details Operations
• Sophisticated UI Controls (widgets)
• Quick data store updates
• Real-time information feeds

When I shouldn’t

Simple forms.

Even though forms are the single biggest beneficiary of “Ajaxification,” a simple comment form, or submit order form, or other one-off rarely used form does not benefit from Ajax driven submission. Generally, if a form is not used much, or it’s critical to work properly, Ajax is not that helpful.

Search.

LiveSearch on blogs is more annoying than useful. There’s a reason that Google Suggest is staying in beta and not going on the front page of Google. Searching on Start.com or Live.com doesn’t allow use of the back button to see a previous search, or previous pages.

Basic navigation.

In general, driving basic site/application navigation using Ajax is an awful idea. Why would anyone want to spend time writing code to emulate the browser behavior when they could spend time making their application better? For basic navigating between documents, Javascript doesn’t help.

Replacing a large amount of text.

Ajax saves a complete refresh of the page, so small pieces of the page can be more dynamically updated. But if nearly everything on a page is changing, why not just request a new page from the server?

Display manipulation.

Even though it seems that Ajax is purely a UI technology, it’s not. It’s actually a data synchronization, manipulation and transfer technology. For maintainable and clean web applications, it’s a good idea not to have Ajax/Javascript manipulate the interface directly at all. Javascript can stay separate and simply manipulate the XHTML/HTML DOM, with CSS rules dictating how the UI displays that data. See this post for a simple example of using CSS instead of Javascript to control display.

Useless widgets.

Sliders, drag and drops, bouncies, mouse gestures, whatever. Mostly these widgets can be replaced with more intuitive controls, or eliminated altogether in favor of simplicity. In picking colors, maybe a slider widget is useful to pick the exact shade. But in picking a price point in a store, a slider to pick the price to the cent is just overkill.

Why Ajax sucks

Bookmarks

Using AJAX to asynchronously load bits of content into an existing page conflicts with the way we are used to navigate and create bookmarks in modern browsers. Because viewing some part of the page information no longer corresponds to a newly loaded page, the browser history and bookmarks will not be able to restore the exact page state.

History

Also, clicking the Back button in a browser might not have any effect, since the URL was unchanged (even if parts of the page were changed). To overcome these problems you must implement a way to save the current page state programatically so that it can be restored later on, when called from a bookmark or from the browser history.

Accessibility

The biggest concern with AJAX is accessibility. This is because not all browsers (especially older ones) have complete support for JavaScript or the XMLHttpRequest object. Some of the visitors do have browsers with the required features, but they choose or have to turn off JavaScript support. When you design the application you must make sure that a fail-safe solution exists for those users, so it can be accessed by anyone. Further more, the way to access and use the XMLHttpRequest object in Internet Explorer and other browsers is different, which leads to a fork in the code and the need to treat each case separately.

How it works…

Following are the essentials for working with AJAX:

HTML, CSS, XML, any server-side technology and JavaScript

Ajax Frameworks

1. Pure JavaScript libraries – provide core remote scripting.
2. Server-based AJAX libraries – generate the AJAX code from your server application.

Following are some of the most popular AJAX libraries:

• AjaxPro
• ASP.NET AJAX Extensions
• Direct Web Remoting (DWR)‏
• Google Web Toolkit (GWT)‏
• Dojo
• Prototype
• xAJAX

Who’s using Ajax

Rightly said, images speak louder than words…

Getting started…

Here are some handy references to get started…. NOW :

So start rockin…!!!And stay tuned for my next blog on the how to implement Ajax in the real world…

–Gautam

admin