Showing posts with label ux. Show all posts
Showing posts with label ux. Show all posts

12/27/2013

BYOX, Security, UX, Responsibility

There are 2 sides to adopting mobility. First is desire for innovation, the opportunity to drive better business with new technologies and thus increase revenue. Second is the fear of changes, the threat of holes in new processes which could result in enormous losses. Today I'd like to talk about the balance between these two sides, the balance between usability and security.


The Opportunity 
(thoughts of a typical employee)

My day-to-day job requires lots of documents' processing and working with my company's internal tools. It also requires leaving to other offices, thus spending about 20% of my work time out of the office. I often save copies of documents on my laptop and mobile devices to be able to work with them on the move. It helps me doing my job faster. But recently all our department had to enroll for a program which forbids any storage of work documents. From now on I take pictures of most relevant documents. I realize that it's a security threat, but I'd better get my job done than conform to overrated security policies.

The Threat 
(thoughts of security officer)

My company operates extremely sensitive data. Its exposure may result in my company's bankruptcy. I control its storage by locating data centers in my own premises. I control its flaw by using secure mailing services from providers I can trust. Recently I got acknowledged that this data is under a great threat, because employees use tools to keep it on their mobile device. Fortunately I've overcome this challenge by introducing MDM solution into everyone's device. I've protected the data from any other usages by strict policies, which all of the employees are obliged to follow.

The Conflict
We see a typical clash of interests. An employee just looks for the easiest way to get his job done. Security officer wants to make sure its done in a safe way. Both are right. So where is the solution?
Which one should change the attitude? A user, who has signed security policy and will respond for violating it, or security officer, who's responsible for any data leakage?
I believe from this point I'm switching from objective to subjective thinking.

The Irony
I'll rephrase the last question. If data gets leaked, who will suffer more? The employee, who gets fired, pays fine and potentially goes to jail, or the Company, which will go through numerous courts and potentially cease to exist? Or put it other way - who's more aware of this risk? Whose interest it is to protect the data? Who should adapt to the situation? You see where I'm driving at.
The irony is that regardless of how much we try, we can't force people to drop their habits, change their own ways of doing things and impose our rules. The best we can do, is encourage them to switch to a new way, which would conform them even better. And here's why

The Good, The Bad and The Lazy
Back in 2007, Apple did a wonderful thing. They made it so simple to use a mobile phone, and so functional in a meantime! This have set a very high standards of expectations from users. As things got simpler people got lazier. And now an app can't be considered competitive unless UX is intuitive. If people need to make more than trivial efforts to get what they want from app they simply quit and use another one. That's where we've brought ourselves, that's what consumerization of IT is.

The Clash
And now this big wave of consumerization is getting into the enterprise. The world where large systems with dozens of buttons on one screen and frankly complex UX has been a standard for years, gets hit by these small screens and highly trivial use cases. The employee and simplicity of his actions start to be the priority. Ignoring this priority means that employee will be much less productive, or worse - he'll find another way to complete his action, bypassing all our validation and security rules
thanks for pic @daveslocombe
The Responsibility
But using fancy apps is not the same as using enterprise software. Work is not always fun and simple. And that's the part where users have to realize their responsibility as an employee. This is the difference between enterprise and consumer apps. Employees still have to use the app, even if they don't like it.
Their productivity is another question though.

The End
It's not about who's responsible for failure, it's about avoiding it. It's just that in this case, limitations are less effective than flexibility. It's possible to achieve same security goals without losing much productivity.

The Reality
I'd like to conclude with a real life example of what happens when employees are forced to the job they don't want to. I witnessed it 2 weeks ago, after I started writing this article. It was the middle of Ukrainian revolution 2013, November 11th, Kiev. People were protesting for 3rd week, and one night government gave order to stop the protest by "cleaning" the protesters by force. But most of the policeman didn't feel like fighting their co-citizens, who didn't do nothing wrong. They still couldn't refuse following their orders, otherwise they'd be arrested themselves. So what it ended up with was a very weak attack from police, with policeman uncertainly pushing the people. This resulted in strong victory by the protesters, who stood their ground and defended themselves, thus total failure of government's plans

12/20/2012

Android vs. iOS: UI/UX Differences


Challenge

Create application that supports both platforms (iOS and Android) and has a similar functionality optimized for interaction design principles and users expectations unique to each platform.

Environment

The important thing to keep in mind is that iOS and Android environments are based on unique for each platform guidelines, user interaction architecture and design patterns. There is a number of iOS and Android similarities in look and behavior of various UI components like

  • information structure; 
  • basic UI elements (sliders, checkboxes, tabs, text boxes, fields etc.); 
  • list-based navigation; 
  • majority of gesture touch controls (excluding “tap and hold” gesture, which is commonly used to reveal contextual bar with options or enter a data selection mode).

However the number of differences is worth paying attention to. Below you may find a short overview of the core design peculiarities that should help better understand differences in the design approach for both Android and iOS.

1. “Back” navigation. 
In iOS applications “back” option is placed in the upper-left corner of the navigation bar. It is used to navigate backward within the defined screens in the application however it is not used to navigate backward across the entire device.
In Android devices there are two types of “back” actions: “up and “back”. “Up” is placed in the upper-left corner of the top bar and is used to navigate up the application’s information hierarchy. In contrast, “back” option is presented as a button on the physical device that allows navigating backward across the entire device.
Back navigation in GMail for Android and Dropbox for iOS

2. Top navigation. 
In iOS applications tab navigation is placed at the bottom of the screen. In addition, according to iOS guidelines there are no more than 5 tabs displayed at a time.
In Android applications tabs are recommended to be placed at the top of the screen. Besides scrollable tabs are allowed to be used in case there are more tabs than can fit in the viewable screen width.
Top navigation in Google Play and Dropbox for iOS
3. Switching between various data views.
In iOS applications switching between views of the single set of data is typically done through the bar divided into segments.  Each segment is responsible for one view.
In Android applications switching between views is done through the UI control “spinner”. This control is presented like a drop-down list of options. “Spinner” is usually placed at the top action bar.
Switching between data views in Google Calendar for Android and iOS Calendar
4. Search.
In iOS applications the searching UI control is placed at the top of the screen mainly.
In Android applications several searching options are available:

  • “search bar” at the top of the screen that is similar to the iOS approach. However the bar is hidden until the user clicks on the search icon;
  • “search widget” that can be placed anywhere within the application interface. Coomonly it is used within the application’s action bar at the top of the screen.

Search in Google Play and Foursquare for iOS
5. Actions. 
In iOS applications can be accessed through the toolbar that contains action buttons, through the action button that is in the upper-right corner hand side of the navigation bar or through the buttons within the interface screen.
In Android applications it is recommended to display actions in the action bar at the top of the screen. If there is any need in displaying more actions than can fit on the action bar, either an action overflow icon appears on the action bar for devices that don’t have a hardware “menu” button, or the user accesses additional actions by pressing a hardware “menu” button on devices where there is one. Android applications may also use contextual action bar. A contextual action bar is a temporary action bar that overlay the app's action bar for the duration of a particular sub-task.
Actions in GMail for Android and GMail for iOS
6. Screen sizes and resolutions. 
iOS phones, for instance, come in two screen sizes and three resolutions (including the latest iPhone 5).
Android devices are represented by a lager list of screen sizes and screen resolutions. This issue has a significant impact on the layout while designing the application.

Summary

It may appear as the straightforward idea to create one application for both platforms however important issue to consider is that interface elements of both platforms are not the same.
Though application’s core features and functionality may be the same on both platforms application’s interface should follow specific for each platform guidelines. Therefore to meet user expectations and ensure smooth user experience application’s design should be adapted to the unique platform design patterns and respect native UI standards.

by Iryna Pantel, UX Designer

11/28/2012

Open-source WPF Layout to Layout Transitions library

Modern users are cockered with well-designed fluid UIs. Based on our own experience we know what an wow effect can layout to layout transitions make for application. Unfortunately, by this time there were no free and open source solution to support them in WPF. Yuriy Zanichkovskyy has implemented an open-source library that for Layout-to-Layout transitions in WPF. You can find detailed description of the library on CodeProject and fork the code on GitHub.

9/21/2012

How does good web application look like? Part 1: user point of view.


People often say that software is "good" when they are satisfied with it. But it is tricky to describe what are objective criteria for "good" software. Moreover, it may mean absolutely different things for various people. Recently we've asked ourselves how do we see ideal web application. What characteristics should it have? What is important and what isn't?
We prepared short list of characteristics that we think should be here for almost any web application that pretends to be called "good". We divided this list into three parts. Today we would like to share first part of this list - how does application look like from user point of view.

So, what is important for users?

  1. Usability. By usability people usually mean ease of use and learnability for user. If you have poor usability in your enterprise system you have to spend lots of time and money to train your users and even it may not help. For consumer market poor usability usually means you lost lots of users just because they don't understand how to use your system. 
  2. Globalization. Ability to adapt to language and cultural specifics of various target markets. You don't have to globalize your application if you target local market. But in case you have big plans for total world domination you have to take care about this. 
  3. Multiplatform Optimization. Ability to operate efficiently on various platforms and browsers (including mobile). Ten years ago it was pretty easy to make your application available for almost any user. Simply because almost all of them were using Internet Explorer on their desktop PCs running Windows. Nowadays this is no longer the truth - you have to deal with various browsers on various operating systems running on various hardware. And don't forget about native mobile clients for your service!
  4. Customizability. Ability to customize system UI and behavior according to particular user needs. Little bit controversial characteristic for web application. There are some people who say that you don't have to allow users to customize your application, because users don't actually know how it should look and behave like. But sometimes it is important to provide this sort of freedom to them. 
  5. Responsiveness. Ability to respond to user interaction within a given time period. Nobody likes application that freezes after some action and don't show any progress to a user. User should be able to interact with application even if it is performing some complex long running task at the moment. Sometimes it makes sense to change the way your application interact with user completely in order to make it more responsive. 
  6. Bandwidth Awareness. Efficient usage of network channel between system and user. It is critical for big content-delivery services like YouTube. For those users who have fast connection it should show video with HD resolution, but for users that are connected through slow and expensive 3G it should consider to show video with less amount of traffic. 
  7. Search Engine Friendliness. Ease of index by search engines, conformity with SEO best practices. If you want your service to be indexed by search engines you have to think about it from the very beginning. Correct usage of things like human-readable URLs, semantic markup and permalinks can be the differentiator for your service that puts it into first place on Google Search Result page. 
  8. Social Media Integration. Integration with social networks: sharing, friends' recommendations, etc. Social networks changed Web dramatically during last couple of years. If you deal with consumer market you should integrate at least with biggest social networks.
  9. Native web stack. Ability to run on browser without need to install any additional plug-ins. Users don't want to install any additional software on their devices to run your application. Sometimes they even can't, because of platform limitations (think iOS, for instance). So, you have to rely only on native web stack. Thankfully, HTML5 adoption is growing so fast.
  10. Accessibility. Ease of use for users with disabilities or specific needs. You should think about accessibility if you want to make your service available for every single person. You must to do it if you do, for instance, some e-government solution and accessibility is strict requirement for your system.

Next time we will tell you about things application developers and operation team are aware of. Stay tuned!