Payment of ₹ requested by HONEY VIG. Click the link to pay securely via Razorpay: Make 5000 payment Payment of ₹ requested by HONEY VIG. Click the link to pay securely via Razorpay: Make 5000 payment ⭐ If you would like to buy me a coffee, well thank you very much that is mega kind! : https://www.buymeacoffee.com/honeyvig
Hire a web Developer and Designer to upgrade and boost your online presence with cutting edge Technologies
Showing posts with label Design patters. Show all posts
Showing posts with label Design patters. Show all posts

Saturday, June 9, 2012

Design Patterns: When Breaking The Rules Is OK

We’d like to believe that we use established design patterns for common elements on the Web. We know what buttons should look like, how they should behave and how to design the Web forms that rely on those buttons.
And yet, broken forms, buttons that look nothing like buttons, confusing navigation elements and more are rampant on the Web. It’s a boulevard of broken patterns out there.
This got me thinking about the history and purpose of design patterns and when they should and should not be used. Most interestingly, I started wondering when breaking a pattern in favor of something different or better might actually be OK. We all recognize and are quick to call out when patterns are misused. But are there circumstances in which breaking the rules is OK? To answer this question properly, let’s go back to the beginning.

The History of Design Patterns

In 1977, the architect Christopher Alexander cowrote a book named A Pattern Language: Towns, Buildings, Construction, introducing the concept of pattern language as “a structured method of describing good design practices within a field of expertise.” The goal of the book was to give ordinary people — not just architects and governments — a blueprint for improving their own towns and communities. In Alexander’s own words:
At the core… is the idea that people should design for themselves their own houses, streets and communities. This idea… comes simply from the observation that most of the wonderful places of the world were not made by architects but by the people.
Street cafe
Street cafe in San Diego (Image credit: shanputnam)
A pattern — whether in architecture, Web design or another field — always has two components: first, it describes a common problem; secondly, it offers a standard solution to that problem. For example, pattern 88 in A Pattern Language deals with the problem of identity and how public places can be introduced to encourage mixing in public. One of the proposed solutions is street cafes:
The street cafe provides a unique setting, special to cities: a place where people can sit lazily, legitimately, be on view, and watch the world go by. Therefore: encourage local cafes to spring up in each neighborhood. Make them intimate places, with several rooms, open to a busy path, where people can sit with coffee or a drink and watch the world go by. Build the front of the cafe so that a set of tables stretch out of the cafe, right into the street. The most humane cities are always full of street cafes.
For those interested in going further down the pattern 88 rabbit hole, there is even a Flickr group dedicated to examples of this pattern.
The jump from architecture to the Web was quite natural because the situation is similar: we have many common interaction problems that deserve standard solutions. One such example is Yahoo’s “Navigation Tabs” pattern. The problem:
The user needs to navigate through a site to locate content and features and have clear indication of their current location in the site.
And the solution:
Presenting a persistent single-line row of tabs in a horizontal bar below the site branding and header is a way to provide a high level navigation for the website when the number of categories is not likely to change often. The element should span across the entire width of the page using limited as well as short and predictable titles with the current selected tab clearly highlighted to maintain the metaphor of file folders.
This is all very nice, but we need to dig deeper to understand the benefits of using such a pattern in digital product design.

The Benefits Of Design Patterns

Patterns are particularly useful in design for two main reasons:
  • Patterns save time because we don’t have to solve a problem that’s already been solved. If done right, we can apply the principles behind each pattern to solve other common design problems.
  • Patterns make the Web easier to use because, as adoption increases among designers, users get used to how things work, which in turn reduces their cognitive load when encountering common design elements. To put it in academic terms, when patterns reach high adoption rates, they become mental models — sets of beliefs in the user’s mind about how a system should work.
Perhaps the strongest case for using existing design patterns instead of making up new ones comes (once again) from architecture. In the article “The Value of Unoriginality,” Dmitri Fadeyev quotes Owen Jones, an architect and influential design theorist of the 19th century, from his book The Grammar of Ornament:
To attempt to build up theories of art, or to form a style, independently of the past, would be an act of supreme folly. It would be at once to reject the experiences and accumulated knowledge of thousands of years. On the contrary, we should regard as our inheritance all the successful labours of the past, not blindly following them, but employing them simply as guides to find the true path.
That last sentence is key. Patterns aren’t excuses to blindly copy what others have done, but they do provide blueprints for design that can be extremely useful to designers and users. And so we do need to stand on the shoulders of designers who have come before us — for the good of the Web and users’ sanity. Many have tried to document the most common Web design patterns, with varying levels of success. In addition to the Yahoo Design Pattern Library, there’s Peter Morville’s Design Patterns, Welie.com and, my personal favorite, UI-Patterns.com.

When Patterns Attack

Here’s the “but” to everything we’ve discussed up to now. There is a dark side to patterns that we don’t talk about enough. One doesn’t simply copy a pattern library from a bunch of random places, put it on an internal wiki and then wait for the magic to happen. Integrating and maintaining an internal design pattern library is hard work, and if we don’t take this work seriously, bad things will happen. Stephen Turbek sums up the main issues with pattern libraries in his article “Are Design Patterns an Anti-Pattern?”:
  • Design patterns are not effective training tools.
  • Design patterns don’t replace UX expertise.
  • Completeness and learn-ability are in conflict.
  • Design patterns take a lot of investment.
  • Design patterns should help non–UX people first.
This article isn’t meant to discuss these issues in detail, so I highly recommend reading Turbek’s post.
For the purpose of this article, let’s assume we’ve done everything right. We have a published and well-known pattern library that enjoys wide adoption within our organization. We treat the libraries as guidelines and blueprints, not laws to be followed without thinking about the problem at hand. The question I’m particularly interested in is, when is it OK to break a widely adopted design pattern and guide users to adopt a new way of solving a problem?

When We Attack Patterns

Despite all of their benefits, most of the Web seems to have little respect for patterns. The most glaring examples of broken design patterns are found in Web forms. Based on years of research, we know how to design usable forms. From Luke Wroblewski’s book Web Form Design to countless articles on things like multiple-column layouts and positioning of labels, we don’t have to guess any more. The patterns are there, and they’re well established. And yet, we see so many barely usable forms online.
As an example of a broken form pattern, look at the registration form for Expotel below:

Notice the small input fields; the left-aligned labels, with the miles of space between them and the input fields; the placement and design of the “Close” and “Register” buttons, which actually emphasize “Close” more. Oh, and what is a “Welcome Message”? Where will it be used? We can all agree that this is not good form design and is not a good way to break a pattern.
But passing judgment on a broken pattern is not always as easy as it is with the example above. Google’s recent decision to remove the “+” from the button to open a new tab in Chrome came under a bit of fire recently. It breaks a pattern that has been included in most browsers that have tab-based browsing as a feature, and yet Google claims that it did user research before making this change. Was this the right decision?
Google New Tab
And then there are UIs that we might not know what to make of. iOS apps such as Clear and Path introduce new interactions that we haven’t seen before — to much praise as well as negative feedback. A step forward in design or failed experiments?
As with most design decisions, the answers are rarely clear or black and white. A tension exists between patterns and new solutions that cannot be resolved with a formula. Users are familiar with the established way of doing things, yet a new solution to the problem might be better and even more natural and logical. So, when is changing something familiar to something different OK? There are two scenarios in which we should consider breaking a design pattern.

The New Way Empirically Improves Usability

One of the dangers of iterating on an existing design is what is known as the “local maximum.” As Joshua Porter explains:
The local maximum is a point at which you’ve hit the limit of the current design… It is as effective as it’s ever going to be in its current incarnation. Even if you make 100 tweaks, you can only get so much improvement; it is as effective as it’s ever going to be on its current structural foundation.
With patterns, it could happen that we continue to improve an existing solution even while a better one exists. This is one of the pitfalls of A/B testing: it does a great job of finding the local maximum, but not for finding those new and innovative solutions.
We gain much from incremental innovation, but sometimes a pattern is ripe for radical innovation. We need to go into every design problem with our eyes wide open, eager to find new solutions, and ready to test those solutions to make sure that we’re not following bad intuition. As Paul Scrivens points out in “Designing Ideas”:
You will never be first with a new idea. You will be first with a new way to present the idea or a new way to combine that idea with another. Ideas are nothing more than mashups of the past. Once you can embrace that, your imagination opens up a bit more and you start to look elsewhere for inspiration.
This is what the Chromium team claims to have done with the “+” button in Chrome. It believes it has found a better solution, and it’s tested it.

The Established Way Becomes Outdated

Think of the icon for the “save” action in most applications. When was the last time you saw a floppy drive? Exactly. Sometimes the world shifts beneath us, and we have to adjust. Failing to do so, we could get stuck in dangerous ruts, as Twyla Tharp attests (quoted by Yesenia Perez-Cruz):
More often than not, I’ve found a rut is the consequence of sticking to tried and tested methods that don’t take into account how you or the world has changed.
The publishing industry knows this better than most. Stewart Curry has this to say in “The Trope Must Die”:
Design patterns can be very useful, but when we’re making a big shift in media, they can sometimes hold progress back. If we look at the evolution of digital publications, it’s been a slow and steady movement from (in the most part) a printed page to reproducing that printed page on a digital device. It’s steady, linear, and not very imaginative, where “it worked in print, so it will work in digital” seems to be the mindset.
This is where the developers of apps such as Clear and Path are doing the bold, right thing. They realize that we’re at beginning of a period of rapid innovation in gesture-based interfaces, and they want to be at the forefront of that. Some ideas will fail and some will succeed, but it’s important that our design patterns respond to the new touch-based world we’re a part of.
Clear Todo App
Our design patterns have to adjust not only to a shift in our interaction metaphors, but to a significant shift in technology usage in general. Tammy Erickson did some research on what she calls the “Re-Generation” (i.e. post-Generation Y) and discusses some of her findings in “How Mobile Technologies Are Shaping a New Generation”:
Connectivity is the basic assumption and natural fabric of everyday life for the Re-Generation. Technology connections are how people meet, express ideas, define identities, and understand each other. Older generations have, for the most part, used technology to improve productivity — to do things we’ve always done, faster, easier, more cheaply. For the Re-Generation, being wired is a way of life.
Expectations of apps and services change when everything is always on and accessible. We become less tolerant of slow transitions and flows that are perceived to be too complex. We are being forced to rethink sign-up forms and payment flows in an environment where time and attention have become scarcer than ever. We don’t have to reinvent the wheel, but we do need to find better ways to keep it rolling.

The Informed Decision Is The Right Decision

Design patterns bring many benefits, as well as some drawbacks to watch out for. But we’d be foolish to ignore these helpful guidelines. There is no formula for what we need to do; rather, we need to operate within certain boundaries to ensure we’re creating great design solutions without alienating users. Here is what we need to do:
  • Study design patterns that are relevant to the applications we are working on. We need to know them by heart — and know why they exist — so that we can use them as loose blueprints for our own work.
  • Approach each new project with a mind open enough to discover better ways to solve recurring problems.
  • Stay up to date on our industry (as well as adjacent ones) so that we recognize external changes that require us to rethink solutions that currently work quite well but might be outdated soon.
In short, we can neither follow nor ignore design patterns completely. Instead, we need a deep understanding of the rules of human-computer interaction, so that we know when breaking them is OK.

Monday, June 4, 2012

Getting To Know The Android Platform: Building, Testing And Distributing Apps

When iOS started to gain momentum, soon after the first iPhone launched, many businesses started to pay attention to apps. The number of apps for iOS grew exponentially, and every company, big and small, rushed to create their own app to support their business.
For some time, iOS was the only platform you really had to care about. The audience was there. For a few years now, there has been another player in the market. Android’s marketshare growth has been phenomenal, and it simply cannot be ignored anymore. There are over 200 million Android users in the world—almost double the numer of iOS users. For businesses, reaching the Android crowds is potentially a very lucrative investment.
Android as a platform can appear intimidating to new players. Blogs and media are littered with articles about Android fragmentation and malware. The Android platform can feel complex, although it is very flexible. However, before getting started with an Android project, understanding the platform and ecosystem is imperative. Trying to apply the methods and tools that work on other platforms could lead to disaster.
In this article, we’ll explain parts of the application-building process and ecosystem for Android that could cause problems if misunderstood. We’ll talk about an approach to building a scalable app that looks and feels right at home on Android, and we’ll cover how to test it and your options for distributing it. The following topics would each need a full article to be explained fully, but this article should provide a good overview. After reading this article, you should have a good understanding of what kinds of decisions and challenges you will face when creating an Android app.

olution is to enable the user to swipe between tabs. This interaction model is not new, but in its latest release, Google has made it commonplace in Android apps. All bundled apps now support this interaction on tabbed UIs, and users will expect it to work in your app’s tabbed screens, too.

Android UI Patterns Can Put Users at Ease

Some UI patterns have become popular on Android — so much so that they are starting to define the look of Android apps. The action bar, one of the most popular patterns, is now part of Android’s core libraries and can be used in any app running on Android 3.0 and up.
Good third-party libraries are available to bring the action bar to apps that run on older versions of Android. ActionBarSherlock is very stable and supports multiple versions and even automatically uses the native action bar when it detects a supported version of Android.
Another popular UI pattern is the dashboard. Many apps with a lot of functionality use the dashboard as their landing screen to give users a clear overview of and easy access to the app’s most important functionality.


Google Play (left) and Evernote (right) both put an action bar at the top of their screens to provide quick access to contextually relevant actions. Evernote’s landing screen clearly tells the user what they can do with the app, while providing easy access to those actions every time the app launches.

Integrate The App With Other Apps

The Android platform provides a powerful mechanism for apps to extend each other’s functionality. This mechanism is called “intents.” Apps can register to receive and launch intents. When an app registers to receive intents, it must tell the system what kind of intents it can handle. Your app could, for example, tell the system that it can show pictures or open Web page URLs. Now, whenever another app launches an intent to view an image or a Web page, the user has the option to choose your app to complete the action.


Social Network Integration

On other mobile platforms, if an app wants to share something to Twitter, Facebook or another social network, it implements the sharing mechanisms internally in the app. Sharing requires a separate operation for each social network. On Android, this can be achieved more easily using intents. An app may launch an intent telling the system that it wants to share an image or text. Depending on which apps the user has installed, the user will be provided with a list of apps that can handle the operation. If the user chooses a Twitter or Facebook client, the client will open to its sharing screen with the text or image prefilled.

Large preview.
There are many benefits to integrating with social networks using intents rather than implementing sharing directly from your app:
  1. Close to zero effort is required to build the functionality.
  2. Users don’t have to log into a separate application. The social network’s app takes care of logging in.
  3. You don’t have to limit the social networks that users may use to share from your app. All apps installed on the user’s device are available to be used.
  4. If a social network’s sharing protocol changes, you don’t have to worry about it. That service’s app will be updated to reflect the changes.
  5. Users might be using an unofficial app for a social network. Using intents, they may continue using their app of choice with the interface they are familiar with.
  6. The intents mechanism offers only options that the user actually uses (i.e. the apps that they have installed). No need to offer Facebook sharing to someone who doesn’t have a Facebook account.

Think of Other Opportunities

Extending the functionality of other apps via the intents system will benefit your app, too. Perhaps your app wouldn’t get used every day and would get buried under apps that are used more often. But if your app extends the functionality of other apps and keeps popping up as an option every time the user wants to perform an action that your app can handle, then it will be thought of more by users.
Intents have limitless possibilities. You can build your own intents hierarchy to extend certain functionality to other apps, in effect providing an API that is easy to use and maintain. You are essentially recommending to users other apps that complement yours and, in turn, extending your app’s features without having to write or maintain any code. The intents system is one of the most powerful features of the Android platform.

Quality Control

With the massive number of devices, testing an Android app is much more difficult than testing an iOS app. This is where the fragmentation causes the most problems. Testing on one or two devices is not enough; rather, you have to test on a variety of screen sizes, densities and Android versions.
In addition to what you would normally test on any other platform, you should the following:
  • Test your app thoroughly on the lowest Android version that it runs on. Accidentally using an API that isn’t actually available at runtime on some devices is easy.
  • Test that the search button works on all relevant screens.
  • Make sure that the D-pad and trackball navigation work on all screens.
  • Test all supported screen densities, or at least extra-high, high and medium. Low-density devices can be difficult to find.
  • Test on at least one tablet device. But try to test on as many screen sizes as possible.

Testing in the Cloud

New services are popping up to ease the pain of testing on multiple devices. Services such as Testdroid enable developers to test their apps on multiple real devices through a Web interface. Simply upload your app’s package and automated testing script, and the service executes your scripts on dozens of devices. Results can be viewed in a Web browser. Examining screenshots from different devices is even possible, to ensure pixel-perfect UIs.
Testdroid cloud screenshot
Testdroid is a cloud service for testing Android apps on multiple devices.

Distribute The App

Once your app is tested and ready, you need to get it to users. You’ll have to choose how to do it. Very few Android devices are restricted to one app store. The overwhelming majority of Android devices ship with Google Play, which is the most important route to reaching users on the platform.

Google Play

The Google Play store doesn’t have a formal process for approving apps. Any application package uploaded to Play will appear in the store’s listings to users. App guidelines do exist, but they are enforced only if there are complaints, and even then pretty randomly. This means that your app will be swamped by hundreds of other apps of varying quality.
So, how to rise above the masses and get the attention of users?
The first 30 days are important! Your app will appear in the listing for new paid or free apps during that time. Ranking relatively high in this listing during this time is much easier than ranking high in the overall top lists. Make sure that your app’s website links to Google Play from the start, and use all social networks to tell people about your app’s launch.
Getting recognized as a trusted brand is difficult. Google Play contains many apps that use registered trademarks without permission. Users have come to learn that a logo is no indication that an app was actually produced by that logo’s company. To increase trust, make sure the “Visit Developer’s Website” link points to the official website, and if possible link back to your app from there.

Top new apps on Google Play.
Making an app work on all devices is sometimes impossible. Some devices lack the required hardware or simply run an old version of Android for which the required APIs don’t exist. You can list all of the requirements in the app’s manifest file, telling Google Play which devices the app is meant for and, thus, hiding it from listings that are being viewed on incompatible devices. But sometimes even that isn’t enough. In these cases, Google Play allows developers to prevent certain devices from downloading their app. While this option should be used only as a last resort, it is still better than allowing users to download something that you know does not work on their device.

Alternative App Stores

Google Play is not the only place to distribute your app. Amazon’s Appstore has lately gained attention due to the launch of Amazon’s Android-based Kindle Fire tablet. Amazon’s approach is fairly similar to Apple’s in that it has a formal review process. The Appstore is also accessible to non-Amazon devices, but currently only in the US.
Multiplatform app store GetJar also distributes Android apps. GetJar has a lot of users and is a well-known and trusted source, especially among people with not-so-smart phones.
Barnes & Noble’s app store is a US-only eBook-based app store. Unlike Amazon’s, it is accessible only to B&N’s Android hardware.

Multiple App Stores, Just One, or None?

Many people’s first instinct is to try to get their app into all stores. This decision should not be made lightly, though. Distributing through multiple stores might make the app reach more potential users. However, being spread across multiple app stores could prevent the app from ranking as high as it could in the listings for downloads and ratings. Having a thousand installations across three app stores might sound better than having two thousand installations in one store, but maybe those two thousand would push the app into a more visible spot in the store and help it rocket to tens of thousands of installations later.
An app doesn’t have to be in a store at all in order to be installed on devices. Android apps can be installed directly from websites or by transferring them from computer to phone. While you wouldn’t reach the same audience and wouldn’t benefit from the update mechanisms in app stores, there is definitely a place for direct distribution. Using forums and websites, developers can distribute their apps to alpha and beta communities without having to risk their reputation or low ratings in an app store. Distributing a major update or an unstable build to a limited number of dedicated testers and fans might be worth the extra effort.

Conclusion

Building a scalable and functional Android app is not impossible, but it requires careful planning and an understanding of the target platform. A blind approach or simply borrowing a design from another platform would likely end in failure. Achieving a successful end requires that you use Android’s tools correctly and follow the right design approach. Writing an Android app takes effort, but if done right, the app could reach a massive numbers of users.

Further Resources

Intents:
Supporting multiple screen sizes:
Android design:
Useful libraries: