Monday, 18 November 2013

Difference between Wireframes, Prototypes, Mockups in android application development

Design of a software product is more than a sketch that roughly explains how it's supposed to look and work. It's an elaborate piece of work that allows developers to understand, what must be done, how they must do it, and how long it's supposed to take. A design of high quality, a graphical representation of the app's functionality, is something that distinguishes your software among competitors, and it's something that will persuade them to use exactly your product. And if you are just at the beginning of your software project, the design stage will introduce to you such terms as wireframeprototype, and mockup (well, if you haven't heard of these before), which have substantial, important differences.

We can also mention sketch here, which is the easiest to distinguish, often handdrawn (although there also are special tools for it), reflecting the main ideas and giving an initial understanding of how the software is supposed to look. But from sketches the design stage always proceeds to more sophisticated ways of representation. What's more, wireframes, prototypes, and mockups pursue different purposes. Here they go, one by one.


Wireframes



A wireframe is the least detailed representation of the three. Basically it's the foundation stone of your design. It has to include the most important pieces of your future software. What's important is that it shows what content will be on each screen, how it will be structured, and how the user will navigate the application. Wireframes shouldn't be underestimated because of their simplicity; their representation of design is clear and convenient.

Here is the balance in depicting details - not having too many of them, not using colors, but essentially having the most important things in their place, so that none would go missing in the end. Wireframe allows to generally understand how the development will go. It shouldn't take too much designer's time to create one, if you know well how your software must work.

Having a wireframe of your future product is good for visualizing objectives for developers. A wireframe helps avoid misunderstandings between you and them. They may give raw initial impressions from possible users, and are an absolutely essential part of design in complex software projects. They are useful as a part of documentation, a kind of a sketch with clarifying notes if needed.


Prototypes



A prototype dives deeper into the interaction between the user and the software, it's like a dynamic version of a wireframe. It takes much more time to create a dynamic, clickable prototype than a static wireframe for obvious reasons. A prototype shows not only the content, but the general usability of an application. This simulation of interactions looks close to the final design, and can be user-tested to make sure that the software has high usability - that's one of their biggest practical advantages.

Prototypes are great at revealing and eliminating flaws of the design, planning further steps and making estimations. It's easier perceived by everyone: developers, software owners, possibly investors, who might have no technical background/education. Thus it's a great means of presenting the idea of the software in a detailed way.


Mockups



A mockup is very close to the real visualization of an application, with static representation of its functionality, it allows users to fully see and assess the design. Being a good source of feedback, mockups are highly useful as a part of documentation. They represent the way a real app looks and feels like, with all the colors, graphics, typography - that's why they are easy to perceive and evaluate.


Don't confuse these three terms. Depending on the project and the problems you need to solve, you may have to create up to all of them. Design is a stage that faces a lot of decisions from your side and labor from the designer's side, but the result clarifies tasks for developers, which is necessary for making estimations for implementation. If you start working with a development company, a created design is an independent document that can be used if you decide to change your developers.
- See more at: http://mobidev.biz/blog/telling_the_difference_wireframes%2C_prototypes%2C_mockups.html#sthash.vNFKrm8L.dpuf

Wednesday, 14 December 2011

Android Tutorial for Beginners- Basics

This is Part 1 of a series of articles I plan to write to simplify the new paradigms introduced by the Android platform for developers.

The part 1 will only define and introduce the fundamental building blocks of Android. Later articles will provide sample code focusing on one aspect at a time, more to drive home to concept than to show any great programming skills.

From a developer's perspective, the fundamental building blocks / components of Android are:
1. Activities
2. Services
3. Broadcast Receivers
4. Content Providers.

The means of communication between the above mentioned components is through
1. Intents
2. Intent Filters

The User Interface elements are by using what are called:
1. Views
2. Notifications

Now, having broadly classified the basics, I would like to give a simple definition for each of them, before we can appreciate the need for each of them.

Activity is the basic building block of every visible android application. It provides the means to render a UI. Every screen in an application is an activity by itself. Though they work together to present an application sequence, each activity is an independent entity.

Service is another building block of android applications which does not provide a UI. It is a program that can run in the background for an indefinite period.

Broadcast Receiver is yet another type of component that can receive and respond to any broadcast announcements.

Content Providers are a separate league of components that expose a specific set of data to applications.

While the understanding and knowledge of these four components is good enough to start development, the knowledge of the means of communication between the components is also essential. The platform designers have introduced a new conpect of communication through intents and intent filters.

Intents are messages that are passed between components. So, is it equivalent to parameters passed to API calls? Yes, it is close to that. However, the fundamental differences between API calls and intents' way of invoking components is
1. API calls are synchronous while intent-based invocation is asynchronous (mostly)
2. API calls are bound at compile time while intent-based calls are run-time bound (mostly)

It is these two differences that take Android platform to a different league.
NOTE: Intents can be made to work exactly like API calls by using what are called explicit intents, which will be explained later. But more often than not, implicit intents are the way to go and that is what is explained here.

One component that wants to invoke another has to only express its' "intent" to do a job. And any other component that exists and has claimed that it can do such a job through "intent-filters", is invoked by the android platform to accomplish the job. This means, both the components are not aware of each other's existence and can still work together to give the desired result for the end-user.

This dotted line connection between components is achieved through the combination of intents, intent-filters and the android platform.

This leads to huge possibilities like:
1. Mix and match or rather plug and play of components at runtime
2. Replacing the inbuilt android applications with custom developed applications
3. Component level reuse within and across applications
4. Service orientation to the most granular level, if I may say

Now that the concept of intent has been introduced, let me get down to a more formal definition of Intent.

Intent is a bundle of information, a passive data structure that holds an abstract description of the operation to be performed. (or in the case of broadcasts, a description of an event that has happened and is being announced).

There are 2 types of intents which I intend to detail in the next part of this series. Before winding up part 1, I would finally also give you a formal definition of Intent filters.

Intent filters are the means through which a component advertizes its own capabilities to handle specific job/operations to the android platform.