Outlook for iOS – job well done!

Acompli released an Outlook like app last year and Microsoft did not waste much of a time in snapping up this company. The result, Microsoft official Outlook for iOS app and in quick time.

Microsoft launched Office for iOS and Android sometime last year.  The lack of Outlook as an app was one of the issue that the company face and turns out, with Acompli, they managed to fill that annoying gap. 

After installing the app, it just feels like I’m using the Acompli app. For now it feels that Microsoft has just rebranded this app to Outlook, made a few updates and launched it. Most of the updates are integrations with Microsoft’s own offerings (OneDrive is now available as an integration). Hopefully Microsoft continues to support Dropbox and Google Drive or other external cloud storage services in the future.

Microsoft’s general manage of Office, told the Verge, “We have been and we’ll continue to update the app weekly”.

Some time back I wrote about the Acompli app while I was on the look out for a decent Calendar app. My feedback still stands the same for the Microsoft Outlook app, however after the rebranding, my perspective for the app changed. I’m looking at this app more from an email client perspective and less from a calendar app perspective. And so far as an email client, it does a great job and at the moment I can comfortably say its one of the best email clients for the iOS – yup, time to replace that slow and weird Gmail app on your phones.

I still continue to use Mailbox simply because I use this app on all my drives – iPhone, iPad, MacBook. With Microsoft Outlook available for all these platform as well, I’m still not sure about their Desktop app. I’m keeping my options open. 

With the launch of Microsoft Outlook, Microsoft has been pushing its Office productivity software to iOS. There is a “preview” version for Android available for now and this only confirms that “iOS first” still holds true.

How much (Prototype) Fidelity?

Following up on my article I wrote some time back, “Wireframing is NOT Prototyping” – a common question that got asked was, well if its not prototyping, what is it and what level of fidelity one should expect?

I have read books and blogs and a lot of them and everyone has one theory which has worked for them.  And the more I read the more I realize fidelity of prototype completely depends on your audience. 

If your company follows an agile model or does not, one of the most common ways to track deliverables is to create an MVP (minimal viable product).  And one of the best ways to create this MVP is by prototyping this experience.  This brings back to our question again – What exactly is prototyping?  I ran a Google search and this is the definition that shows up:


1.   a first, typical or preliminary model of something, especially a machine, from which other forms are developed or copied.

1.  make a prototype of (a product).

So in software terms, prototype is a rough/comparative/almost/close/near/relative something of an experience that allows you to simulate what it is like to use the product or service in question.  This something is the answer to my next question – how much fidelity one should expect?  Similar to wireframes, prototypes should be cheap and one should spend as little effort as possible which is one way to decide on how much fidelity you need.

One of the most important aspects of creating a prototype is to answer some basic questions:

  1. What is it that you want to know/learn from this prototype?
  2. How much time do you have at your hand (let me guess – extremely short)?
  3. And one of the most important – Who is the audience interacting with the prototype?

Why is your audience important here?  Knowing your audience will allow you to create the smallest possible prototype that will yield you maximum feedback.  So if you are tasked to create a prototype to communicate to a group of developers, chances are you are good with just paper and pencil, since they have the ability to focus on the task you are trying to get feedback on and ignore the other parts of the products that remain unaffected.  For example, it wouldn’t bother them if you don’t show a detailed global navigation if you are trying to demonstrate shopping cart interactions. 

When the stakes are high, you get in to extreme details.

I was listening to John Gruber’s “The Talk Show” after the iPhone 6 launch and he mentioned that when Apple decided to make two big screen phones, they made prototype for every 1/10 inch from 4 inches to 6 inches.  The result, 10 million iPhone 6 and 6+ sales in 3 days

Technology is changing us (for the good I think)

In the last ~ten years I have changed my mobile phone a number of times, from Nokia 5110 to Palm Treo to Blackberry Curve to Android Droid X and finally settling down with an iPhone. Its amazing how technology has evolved from large mobile phones to small tiny Nokia phones and back to massivesmartphones phones.

Designing for mobile is different and not just with regards to the shape and size. Because mobile devices are lighter and more portable (in some cases), we find it more convenient to use them. And because we use them so often, we feel a unique, emotional connection to them.

One more thing I realized in the past few week is my transition from being a true Microsoft user to an everything Apple user in the past five or so years. I realize I have every single Apple product and everything is connected to the cloud. I am not talking about the wonderful (pun intended) ecosystem that Apple provides, but my motivation to move everything to Apple. And this does not end with just hardware; of course the transition to Mac OS X was smooth, I missed MS Office (IE was replaced with Chrome a while back). But in the past year, I have seen myself transitioned to iWork and when I think about this transition, I questioned myself why? Why did I move away from a software that I used for almost a decade.

Microsoft Word

Microsoft Word


It struck me when I heard this from my customers complaining about a system that they have used for years. It baffled me that the same users who have used this system for so many years are now finding this system clunky. Why?

Apple Pages

Tracing back to my own transition, I realized how simple Gtalk, Gmail and Chrome browser were to start with. After getting my hands on my first tablet in 2010, I slowly transitioned to Apple mail and it didn’t take me a while to move to iWork when I used their 30 day trial version. The fact that I was not looking at too many things in my face made me feel better. Just like my iPhone (in my case) I could concentrate on a task that I was currently doing rather than find something in that massive ribbon on the top with icons that I found it difficult to understand at times.

We have different attitude, behavior and priorities while using our gadgets. They come with us on the bus, walking down the street or watching TV. Users expect more contextual based actions then an al-a-carte menu system where they are expected to find an action they want to take. Because mobile devices have changed user expectations, it is extremely important to consider them is user studies since their influence is much larger then we can think of.

Wireframing is not Prototyping

With the rise of UX role in the industry, wireframes have played increasingly leading role in the modern world. Its a simple way to validating user interface and layout and are cheaper and faster to produce than a final visual comp.

Wait a minute did I say cheaper and faster? Really?

Over the last couple of years, the number of wire framing tools that have come up in the market is alarming. From a world of Visio, Omnigraffle and to a certain extent Rational Rose in the past, today you have options for any platform. You could do a google search today and you would be surprised to see the number of tools available today and with links to tell you the top 5, 10 & 20 tools for wireframing. With more options today, we run into more complexity.

Paper & Pencil have been probably the cheaper and faster way of evaluating the interface and layout, however I see very little of those today.

Today, there are applications that allow you to create wireframes that look hand drawn.

The last few years the wireframes have looked more and more different and detailed. Images, actual look and feel, every single mouse movement or tap or gesture and what happens next, etc. That definitely throws cheaper and faster out of the window.

Lets look at a classic definition of wireframe


noun: wireframe; plural noun: wireframes; noun: wire-frame; plural noun: wire-frames
a skeletal three-dimensional model in which only lines and vertices are represented.

Exactly, a wireframe is a three-dimensional illustration of a page’s interface that specifically focuses on space allocation, prioritization of content, functionalities available, and intended behaviors. For these reasons, wireframes typically DO NOT include any styling, color, or graphics.

However, with the next generation of devices already here, and with users employing more touch-based system, a few changes should be made in the way we do classic wireframes. In spite of these progressions, though, creating wireframes should remain cheaper & faster.

Today we have taken to wire-framing to actually deliver a full blown spec. Do you think a developer is going to make sense of a step-by-step wireframe that captures every single gesture? (most of the developers/QA know what happens when you click a drop down or on tapping the button it turns blue from grey). These are not High-Fidelity wireframes (if that is your arguing point) but a spoon feeding document which runs into 100’s of pages.

A High-fidelity wireframe has increased level of details which should simply point out details like dimensions, behavior and/or actions related to any interactive element.

There have been some rules that designers need to consider while creating wireframe. Lets see how or what we can change so that wireframes are better suited for today’s interaction. It’s important to keep in mind to use wireframes as guides and not deliver a spec.

Some old school rules:

Do not use colors — If you want feedback on your functionality, do not use colors, however always use a different color to show highlights or selection. Stakeholders always get confused when they don’t see a selection color; in other cases avoid colors.

Do not use images — Images distract from the task at hand. Do not use an image unless it is part of your navigation and you cannot show any interaction with that image. Else just show a placeholder.

Typography — Use one font, but vary their sizes to differentiate.

Keep them short and to the point — Don’t spoon feed. Use annotations and try to capture your use cases.

One of the things old school wireframes always said was to show what things go where irrespective of shape and size since it was important to give the users an idea as to what content goes where. Later on it became important to do wireframes that would show details of content before the web page fold.

Today, users use more touch devices compared to desktops/laptops. Screen sizes have become more important and users don’t have to worry about the web page fold anymore. Every single pixel has become important. Thus making it even more important to deliver pixel perfect wirefames.

One of the biggest down side of delivering wireframes as a spec is that at times you do not know from where to start. Should I do the dashboard now? Oh but making an appointment is more important then looking at summary. At the end, you are scampering to get things done, with 100’s of wireframe slides and still no starting point.

A good technique that I have relied in the past is to write down high-level scenarios for your personas that you create. Once you have these written down; prioritize them — there you have your starting point.

Now take a single scenario and try to come up with uses cases, or business rules whatever you are comfortable with. Start with a single positive use case, document all the business rules. Do your wireframe, as minimal as possible and annotate them if required.

Create a summary page at the end of this, and capture all the negative use cases and error cases. Typically you wouldn’t need wireframes to show these unless you need a different interaction all together.

Keep your wireframes short, simple and annotated and remember to keep them cheaper and faster.