Thinking about companies, in "Small Giants", we have many examples of small companies, but the truth is that those companies are by definition - due to their nature like wineries, food shops, etc; local companies unable to scale without increasing their resource consumption and staff count.

As companies grow they end up having to serve themselves, not just their clients. The Comms overhead increases, requiring patches and fixes like forced knowledge sharing, status meetings, planning meetings, big project management efforts, more. In opposition to that, small companies possess natural knowledge sharing, very frictionless information flow and decision making, status awareness and decentralised project management.

Another funny thing that happens is that even when you place an individual from one of those said small companies on a bigger company his advantages fade away as the processes in place nullify his natural management skills and eventually turn him into a mediocre bee like the rest of the cogs in that company. It's really about context, things don't exist in isolation, small companies have a unique ecosystem that allows for it to exist as it is.

In the web industry it's a different story. We can do business with anyone in the world without scaling up due to the nature of our work, there are no physical constrains and the work we produce is usually, but not necessarily, digital. Meaning the production and delivery of the goods we produce is completely virtual.

Local leads to small, small leads to local?

In web, you can 'harvest' the benefits of contributing to your local community even when your client is an international charity, regardless of their size, although, you'll have no knowledge of their community and that could perhaps hinder the quality of your work. Then again, a small web company can ignore borders and oceans and simply move into the community to better understand it, but it's obvious this will bring extra costs to both sides and is far from perfect.

So, given that, I guess breathing and working local IS the way to go if you're looking to more efficiently and effectively benefit your clients in this situation. Time is money, but time isn't quality, and money isn't necessarily quality, it's all relative and subjective.

An individual with a passion for his job will deliver greater quality for the same time/money a passionless worker would. Passion is a drive that enables you to excell at what you do, work will flow naturally and blend with your life, you'll have more dedication, more data points and valid experience if you shave passion.

Imagine a designer who only thinks about design at work, disregards all that's around him while at home, in the street, the billboards, the copy in it, the websites, the way things work. This designer will have a limited experience, focused on whatever work comes in his direction, and even if he's a freelancer he doesn't breathe design. Lessons may come from unexpected sources, a billboard is a way to experience the work of other designers, look at it, think about it, wonder what can be improved and what's improved in relation to his own approach.

By living his passion he'll be better connected to the knowledge that's around him. This is true wether you're a designer, developer, baker, cook, flight attendant, it's true in many many contexts.

A flight attendant for example, he or she, will eventually travel in different companies other than his own, and even when flying on his own company the value of passion is high, that person will be able to experience the other side of his job, be aware of what annoys passengers, what can be improved, and although an airline can't operate at a small scale,

as small as some people defend a software company should be, there is the possibility of his own company to listen to feedback from 'the bottom'

, would only make sense and has testedgood results in the past in the food industry when employees of a big supermarket chain were given the voice to suggest improvements to their business.

Boy, we started with local and are now into passion.

Case Study

Queer Lisboa Pro-bono film festival website and mobile app by Quodis

Would a large company, on a budget, with no relation whatsoever with the film festival, be able to deliver as good results as a company that's based on the same city where the festival occurs, and where one of the designers is a good friend of the organisers?

Being this close allowed them to know the possible difficulties that people will have to reach the venue, by knowing the venue itself they were able to better structure the information around the film schedule, reducing any possible confusion regarding the layout of the place and room names, but having a close relation to the client they were more compelled to go the extra mile and deliver a custom tailored solution that fits the client' s needs now and with room to improve in the future, reducing long-term costs because they know closely the clients roadmap and future needs, by being a local and having attended previous editions of the festival, the designer had first hand knowledge of what went wrong and what can be improved in future editions and may have a role in eliminating the problems with very low friction.

This is a very romantic view, but it's a real one, this isn't a made up story. You may argue that this doesn't scale, but I say it doesn't have to, that's what we're advocating here, small companies doing enough work for them to live comfortably and having big impact on the people they work with.

There's work for everyone, and if there isn't, no problem, it's a small company, it may be flexible enough to adjust itself to deliver something else that's being demanded, the market will adjust itself.

Work will be better distributed, instead of having big companies gobbling up big chunks of work, it should be evenly distributed over smaller, more competent companies that will deliver in less time and with higher standards.

I haven't addressed one thing: standardisation, this is what enables bigger companies to deliver on budget: cheaper, okay work. This may work on other industries, but it doesn't work in web, unlike the automotive industry, where standardisation made a huge difference and success, the web is a constantly evolving industry. Standardisation will only take you so far, and if we're only focused on delivering, we would have to stop innovating, stop improving at this fast pace in order to be able to standardise our production.

It's a trade off in the end, common to other industries, even with standardisation you either deliver cheap or quality goods, and there's room for both of course, but the good quality ones can change people's lifes. It is also true that what was once premium quality will eventually become the norm, but in order for that to happen, there are many pieces that have to be moved, and they go beyond process, standardisation, skills and will vary hugely between industries.

This is sort of a rough draft, decided to publish it 'cos life's too short to worry about misinterpretations of this article.

Note: HULK says: communication, interaction between companies, local communities = GOOD

Easier to see what works, what doesn't work, exchange experiences, loose the fear of change.

"in business, specially in global (non-local) how much do you TRUST your client, how much PASSION will you have for his business, and how much VALUE are you delivering if this client is 1 out of 1000"

Apple, Kindly Remove Your OS Gestures from My App Canvas

TL;DR of his article

Apple is using the wrong approach by not providing proper differentiation between App and OS gestures. Ideally Apple should have used Edge Gestures, similar to the ones on Windows phones or WebOS. And also, due to the fact you can perform those gestures anywhere on the screen, your app cannot take advantage of them.

That's an interesting and very valid point of view.

I think I can offer a different point of view though.

TL;DR of this article

I think there are also some valid reasons for them to do so.

• enforce simplification of 3rd party apps by reserving complex gestures for non-essential device-wide actions
• uniformization of interactions accross platforms: iOS and Lion share interaction patterns

Canvas real Estate

Regarding Apple's use of the whole app canvas for gestures.

It may not be a bad thing. I'll start by listing a few ideas and show you my point further down below.

Cognitive friction

Gestures like the single finger tap, drag, swipe have very low cognitive friction because very close to the natural interaction we have with objects. We use 2 or more fingers for grasp, to convey a stronger intention, sometimes precision.

Apple has reserved the more complex gestures that require the use of 4 fingers to implement non-essential global gestures.

I don't think it's correct to think about this is a 'logical' way. Perhaps we shouldn't be thinking of the technological details behind the screen, making the separation between App and OS. The reasoning for is that the user doesn't make this distinction. I think it's safe to assume that from his point of view, he's interacting a device as a whole. It has a default state and many extensions he installs.

Apple's global gestures provide an easy way to manage context. Above the App level you have:

• multitask overview - 4-finger drag up / nudge the App
• multitask stack navigation - 4-finger drag / push the App
• home - 4-finger pinch in / shrink the App

If I'm forgetting any, then it probably has more implementation issues than these.

Still in the subject of cognitive friction, I'd like to hear some feedback from people, but I think the 4-finger gestures are so expressive, provide such a great contact level with the device, that anything else than applying an action to the the full canvas wouldn't be natural. That is, outside the context of games and other immersive apps.

Complexity

There's possibly a slight relation to the previous cognitive friction section in here, but yeah, I guess it boils down to it: reducing complexity.

With the complex 4-finger gestures reserved for non-essential interactions, you're left with the most common ones, which is a good thing: simplify your app. Just because you can implement 4-finger drag/swipe/double tap doesn't mean you should abuse it.

Yes, Apple is being very paternalist, again, but I think this might be the resoning behind their decisions.

Also, don't forget there's a greater plan here being put to action by Apple, which is to introduce more direct manipulation gestures in both their mobile and desktop computers.

Lion also leverages 4-finger gestures, also for device-wide actions, like:

• accessing Mission Control - 4-finger drag up
• accessing App Exposé - 4-finger drag down
• switching between Spaces - 4-finger drag
• accessing Launchpad - 4-finger pinch out
• accessing Desktop - 4-finger pinch in

Makes sense they want to reserve these for their own interaction layer. It's hard to miss the similarities between iOS and Lion of these.

Edge UI

As Josh put it, this pattern allows the separation between OS and App gestures, I still stand by my reasoning that this separation shouldn't exist.

From what I've observed so far, this pattern doesn't map very well to the user expectations.

This is based on my observation of people interacting with touch devices. I've noticed people tend to direct the control gestures to the center of the screen, sometimes the bottom if they're lazy, but never initiate a gesture from the edge of the screen.

I don't think there's a proper affordance for this pattern.

Conclusion

Refer to TL;DR.

Input is always welcome.

Do read my other writing on 'Improving gestures in NUIs', where I try to explain the differences between 1:1 and trigger gestures. And how much I prefer 1:1 direct manipulation over triggers AKA button gestures, read the article for more details.

It's isn't the imbalance itself but it's effects and the framework required to support it.

The extra high profit margins being a side effect and objective, an intended side effect then.

And the lack of innovation, an unintended side effect, caused by how well the profit frameworks work and the moving pieces wherein.

Moving pieces such as old distribution channels still yielding results, synthetic, recipe-based content still being accepted by the end user.

Audience conditioning via the powerful distribution channels that offer convenience but calculated content selection.

Content tailored based on the rule of greatest acceptance, that in turn becomes the content of greater demand.

In the past, the information wasn't so broadly available, communication wasn't as effective and immediate as it it today.

People with common ideals couldn't form a bigger distributed mass as easily as today. A mass that empowers them to make themselves heard and take action against what they deem to be against the common good.

In practice, these distributed interest groups are effectively fighting and forcing the big blobs like the music industry adapt and acknowledge they are no longer in their comfort zone. Content can be monetized much easily and the critical revenue mass can be attained very easily.

As Louis C.K.'s experiment demonstrated, the middleman is no longer relevant, there is no longer the need of help in distributing and monetizing your content. Therefore there is no longer room for the middleman to tap onto that resource.

And that's a good thing, we're effectively scaling down, becoming self sufficient and distributed. Without loosing out individuality and opening doors to a wider variety of content due to the possibility of reaching the required niche mass for sustainability of the own niche.

Small people serving other small people, reciprocally. Instead of the usual: Small people plugged into a monolithic sustainable* system.

*sustainable but requiring maintenance, unnatural behaviour, and serving the interests of few.

And did all this began with us? Did we naturally steer away from the old model? Did the market balance itself?

I've been noticing two different implementations of gesture controls on mobile and desktop devices.

The first one, is what it appears to be a gesture trigger, where an action is fired after the gesture reaches a certain threshold.

OSX gestures such as 'Show Desktop', 'Launchpad', 'App Exposé', all implement this pattern.

The second implementation is a 1:1 manipulation of the user interface.

Using the OSX gestures as reference once again, you can see an example of this approach in the 'Switch Space' gesture, where it even allows you to peek into the adjacent desktop and snap back without totally switching between them.

Which one is right?

I think there's room for both, but personally prefer a 1:1 manipulation of the UI.

The gesture trigger is sort of a fallacy in the metaphor, it's a button in disguise:

• Feedback - triggers don't provide feedback until they're fired, that's bad for discoverability, bad for the metaphor of a natural user interface;
• Perception - the lack of, or improper feedback affects user perception of the interface, it stops behaving like an object so the user no longer perceives it as such, your app is one step closer to a synthetic contraption.

Still speaking about the NUI metaphor, if you look at real world objects, their state doesn't vary between on or off, there are usually many intermediate steps.

This isn't true for buttons, switches and other man-made objects obviously.

But the real world is a mess!

Yes it can be a mess and I'm not advocating for things like 3D desktops where you can place your files anywhere or pin them to the virtual wall or whatever.

Our medium is digital, and even though we're designing with the real world in mind: masquerading our bits and bytes as flesh and bone, we should take advantage of that medium.

A digital bookshelf should offer the digital benefit of infinite storage, search; while at the same time present a familiar display of data.

Another way to eliminate that mess is to do intention handling and automatically set the state of the UI to a pre-defined one.

Take for instance the 'Switch space' gesture in OSX, or its brothers: the home screen switching in Android or iOS.

All of them allow for 1:1 manipulation of the interface, but once the user stops giving input via the touchscreen, the interface decides between returning to the previous state or jumping to the next screen.

Continuity & Consistency

A gesture should offer continuity.

Wether if it's a trigger or 1:1 manipulation, a gesture should offer continuous effect over the interface.

Don't force the user to stop and resume the control gesture in order to revert the state of the UI.

An example of a trigger gesture where continuity is respected is the 'Launchpad' gesture on OSX, you don't need to lift your hand to hide it, just perform the gesture in the inverse direction.

The same doesn't hapen with the multitask gesture on the iPad, where you have to stop touching the screen in order to hide the app tray.

Granted, these are artificial examples, as in: continuity isn't really required, but it serves to illustrate my point.

I would also say triggers and direct manipulation shouldn't be mixed in the same app, as it breaks the overall metaphor.

Performance

A very, very important factor in your app, if you offer 1:1 manipulation but if your interface lags way behind the user commands, your metaphor is broken.

To sum it up

Gesture implementations should be as well though as animations in your app. Both tell a story to your user and that story can vary between 'Hello, Frankenstein' and 'Hello, World'.

Notes

Another thing that may impact the overall application metaphor, and still talking about consistency, is the way gesture navigation relates to the information hierarchy.

See Path for example, you can drag the main screen to the left in order to reveal the friends list, but after you select a friend and the app scrolls the ui to the left, revealing the new content coming from the right, you would assume it's possible to swipe right in order to push the UI and go back to where you started. That is not the case, you have to resort to buttons in order to get back.

Flipboard isn't immune either. After selecting a topic, direct manipulation is discarded in favor of triggers, which is okay I guess but not consistent with the initial perception, plus, the trigger has a very low movement threshold. I've notived they're doing something smart here, a speed threshold is also in place and slow gestures are ignored.

One idea for Flipboard would be to make the left swipe bring back the latest selected topic when on the main page, this is sort of related to the continuity issue I raised above. Could perhaps be fitted into error handling as the user may accidentally perform a gesture that takes him back to the home screen with no way to get back (remember he'd been drilling down content on a specific topic and we shouldn't assume he keeps track of the topic at all times).

Also, if you look at certain OSX trackpad gestures videos in the System Preferences, like the Mission Control one, you'll notice they've been manipulated to look like 1:1 manipulation of the UI instead of how they really behave.

And yet another note, do play around with iPad multitouch gestures, the 'Send application to background' - 4-finger pinch-in, features 1:1 manipulation and even allows you to revert the action even when the animation has been 100% completed, provided you don't release the screen. Unfortunately, they first thing people try to do, which is a 4-finger pinch-out doesn't bring the app back to foreground.

TL;DR

KOMNI is a Location-Based Mobile Social Network designed to promote real-life interactions between strangers or friends, as well as interest, location-based discovery of places, events, people.

Its main interaction vector is the mobile and revenue is generated through deals with mobile operators that benefit from increased revenue from mobile phone sales and service usage, and in turn provide visibility for the service.

The duo was composed of Diogo and I, the context of the project was academic. We tried to get funding but weren't successful, the project was iced due to lack of resources.

The Story

The project was first conceived in the summer of 2004, its purpose was to be an exercise that would allow us to put our skills to practice.

It matured along the months, sitting a bit idle between our classes, and finally in late 2005 we started working on it.

We worked on the business case, features, technology, development strategy, and came up with a pretty solid project.

These weren't requirements in our assignment, and weren't even graded, we chose to do this because we wanted to go the extra mile and this was a very exciting opportunity to prove ourselves, create something we liked and solved some of the problems we saw in the social networks at the time - Hi5, Last.fm, MySpace, etc.

It was also great to be able to count on:

• a psychologist - Ricardo, who helped create a market study to assess the viability of the project based on our target audience behaviour, the sample was of 200 people;
• a star web developer - André Medeiros, who introduced us to Rails and modern web development;
• Dora Nobre, Luís Lobato, Rui Lança, Cândida Martins, Inês Medeiros, and more who provided valuable advice and feedback.

Production started in late 2005 through early 2006, 5 months of part-time development that included familiarization with the technologies being used:

• Linux (dev and local);
• SVN (client & server);
• Rails - Agile Web Dev With RoR;
• RadRails IDE.

We did the setup of our development environment, picked an IDE, grabbed a copy of Agile Web Development with Ruby on Rails and got down to business.

The first prototype was a web-only version of the network, it was mainly a demonstration of how we would structure the network and the experience we envisioned for it with a set of basic features. The mobile discovery based on the user's interests and location wasn't implemented as it required R&D, time and deals with Mobile Networks (GPS wasn't common on mobile devices at the time, we needed to be able to access triangulation data, and don't get me started on the precision of that data).

A Service Shaped by Need

User Experience

We hated HI5, MySpace for their awful UX, cumbersome navigation and interaction.

KOMNI's UI was properly structured and tested, with contextual actions clearly separated from website navigation, the design didn't allow the user to mess it up with superfluous customisations like MySpace did that ultimately led to damaging their brand and be seen as 'that crappy website full of sparkling stuff and audio players'.

Mobile, Omnipresent

KOMNI was mainly a mobile experience because we loved mobile and the web, and because we wanted to reach out to people who didn't use social networks because that meant being at home, not outside socializing with friends, and that for them screamed: Looser.

KOMNI would be always with you, proactively notifying you about an event that might be relevant to you because you were frequently near the venue and your interests made it likely you'd enjoy it. Plus, besides suggesting the event it would also suggest people, places and more.

Yes it has a bit of Foursquare, Dating Service, Songkick, Last.fm, but that's the point, it's a useful, relevant service.

Utilitarian

Because we were sick of networks where the generated content and interactivity was purely for leisure, no added value, no benefit for the world.

We wanted a network that besides leisure, would provide value for everyone, similar to what Gowalla tried to do, by offering you thematic lists, KOMNI would allow you to discover places/events/people/music, based on your personal preferences and profile.

Data would be curated by people, ratings, comments, views, attendance, etc.

You, as a tourist in a new city, would be able to pick up a KOMNI-enabled phone and explore the city knowing the suggestions made to you were relevant and not and not a generic 'go here because everybody does', you'd be able to communicate with the local tattoo community if that was your thing, which normally would require you to have an intimate relation with the locals - you'd still be able to forge those but no special previous connections would be required.

Project Details

Features

KOMNI, despite innovative, was a child of its time, it featured:

• User Profiles
• Messaging
• Groups
• Forums
• Medialog - basic blog meant to be updated via sms/mms/videocall
• Mobile Web App
• Discovery - interest and location-based, proactive suggestions
• Child Tracking - yes: safety, control.

Target Audience

The target audience was relatively broad, individuals aged from 16 to 32, living in a dense populational area, medium income.

Tourists (KOMNI Traveler) were also part of our target audience, ideally with a KOMNI device you could rent/buy, and after a few questions the user would be able to take advantage of the already existing data built upon hundreds or thousands of interactions from the local users eg:

• users who like or have tattoos usually visit this shop
• users who like reading in calm places usually visit this place
• users who like Rambo are going to attend the monthly Rambo meetup in place X
• you have node.js in your skills, there's a cool meetup coming up!
• you seem to have a Paleo diet, you're near this neat Paleo restaurant, shall I add this to your todo?
• you're near another Berliner visiting this town, wanna say to him?
• etc

Monetization

The service would be monetized in various ways:

Partnership with a mobile operator

A Mobile operator would provide visibility for the service on their mobile portal, or create a dedicated one, and data on their user's location - to overcome technical limitations of the devices at the time, controvertial.

At the time, there was a MVNO whose target audience was very close to ours, called Yorn by Vodafone, and their market positioning was ideal for our service, they even had very irreverent ads like this one here and were frequently disruptive with their pricing and features. Years later a different Mobile Operator would create their own social network called Tag.

The selected Mobile Operator would: * have a service that promotes the usage of mobile communications - sms/mms/videocalls, * sell devices at a low price tied into the service * attract more users by * offering an innovative service * use a service-centric approach to revenue instead of the (still) current practice of charging for device and service

Promoted content

Companies and Users would be able to promote their events, places, businesses in the service, akin to twitter's promoted content, but in case of KOMNI they would be hyper-targeted and thus increasing their efficiency.

Strategy

Our development strategy was the classic Release Early, Release Often.

We'd implement features gradually, listen to user feedback and metric before evolving the service further.

Project outcome

As mentioned before, the project was put on ice.

I didn't manage to get funding, due to various motives:

• lack of experience and exposure to vc funding;
• lack of skills required to better plan the roadmap, investment requirements;
• very bad attitude when questioned about what's a social network and why should they care about it.

I didn't have the team, network, resources to further develop the service, eventually it faded into the background.

Were I not in Portugal and had these difficulties, KOMNI might've had a different fate.

I kept the service details unpublished for years and never wrote about it until today. The ideas in it lost its freshness over the following months. Twitter, Facebook, Foursquare, Tumblr defined a new social landscape.

From time to time I bump into an article such as:

• 2011/12/23 - Facebook Now Scours Your Account To Suggest Real-Life Events

and think of KOMNI.

There's also a huge list of articles, bookmarks I collected along the years that are related to KOMNI -> pinboard/u:lmjabreu/t:minerva

Minerva - godess of wisdom, was our codename, and there are bookmarks on mobile web apps, DRM and content ownership, mobile browser stats and usage, initiatives from Google, Yahoo, H3, and many other research articles related to KOMNI.

Curiosity

The K in KOMNI comes from a texting trend among the Portuguese youth of replacing the Cs with Ks, it reflects the KOMNI's target audience.

As the list of *-as-a-service’s continues to grow, I thought I’d throw one into the mix. What about the idea of a backend-as-a-service (BaaS)?

The recent surge of client side Javascript frameworks along with the attractiveness of simple RESTful APIs has created an environment where server-side…

I believe web apps can be as good as native apps, especially on iOS.

From the top of my head, Twitter and Asana mobile web apps are two interesting examples of what can be achieved, but there's still room for improvement.

There are many factors that may prevent your web app from being as good as a native one, I'll write a post on that and share my findings. But today:

Improving Mobile Web App Responsiveness

By leveraging Touch instead of the default Click events.

The problem with Click events on mobile browsers is that they come with a 300ms lag, which is OK for websites, but not for controls or app navigation.

Fixing it is as simple as replacing " onclick " with " ontouchstart ", and I've done so on a random library I came accross today: SwipeJS - swipejs.com

**Examples ** (view these on your mobile)

onClick: swipejs.com

onTouchStart: lmjabreu.github.com/Swipe

Notice the responsiveness difference when switching slides it selecting tabs on the touchstart example.

Source if available over at github.com/lmjabreu/Swipe, slapped a chunk of code on both branches to support ontouchstart when available, demo purposes only.

I've already expressed my feelings on twitter: "really, really sweet app but not sure how often I'll use the service."

While I tested the app I also took note of a couple of things that could perhaps be improved, they are:

Signup

Not the whole signup process, just one of the screens in it, the one where you have to choose between creating or logging in to an existing account:

I hesitated a bit on this screen before choosing 'New Path', there are 2 reasons for that hesitation:

1. Path does a great thing first time you start it, it gives you instant gratification by landing you on a sample timeline, that's cool but it also switches the context from registration to interacting with the Path app. In this context, it's not surprising that a dialog that offers you to choose from 'New Path' and 'Existing Path' may not be immediately associated with the account creation workflow.
2. Besides pushing the brand onto you, which is fine, it deviates from the normal signup/login wording.

Personally, I'd stick with one of these:

• Register your Path / Login to Path
• Signup to Path / Login to Path
• Signup / Login

Feedback

This is most likely a bug, but when viewing certain content in the app, there's no visual feedback whatsoever of loading activity.

In the above screen shot, the app is loading the cover picture (currently linen), and the user timeline, the username wasn't visible as soon as I opened the profile either.

Timestamps

They, are, gorgeous.

The tiny clock animated between values, drool.

The only remark I have is regarding their visibility and appearance.

• visibility: easily covered by your finger while scrolling
• appearance: it's very close to a drag handle, popular on Android apps (Quick Scroll), not so much on iOS I believe, the fact that I was an Android user for years may have some impact on this perception.

As @gt points out in his article, they realised the timestamp can be pushed out of the stage and give the content full highlight instead.

That's cool, but perhaps there's another way to do it, if you look at the screen shot above, some of the updates do contain a humanised timestamp, I would suggest to have it always in, but heavily faded out or completely hidden, and bring them into the stage by giving them more contrast when scrolling.

Exact timestamps could be made visible when viewing a single update, and display a more loose timestamp in the timeline.

Another solution that would make it look less like a drag handle would be to display it in a fixed position hovering on top of the timeline for example.

Yet another solution would be to present the bubble on the opposite half of the screen where the finger is pressing, would loose association with scroll position but would minimize the chances of being hidden by the finger.

Swipe Navigation Consistency

Reminiscent of the Twitter for iPad app, Path offers swipe navigation, like so:

On the app home screen you can swipe to the right to reveal the main app navigation, and swipe to the left to view your friends list.

Very cool, they made it optional by providing button fallbacks and use animations to suggest you're able to perform this task.

The problem here is that the same animation is present in other screens of the app leading you in mistake that you can perform a swipe gesture to get back to where you were.

There are a couple of occasions where it's specially misleading, most blatant one I found was when viewing a user profile:

home -> friends list -> user profile

the animation suggested I could go back to my friends list by swiping to the right, but besides not yielding any result, the fallback button took me to the home screen with an animation that suggested a navigation stack similar to:

home <- friends list <- user profile

By performing a swipe to the left I was taken to the friends list:

home -> friends list

Pull to Refresh

Sadly not implemented.

Conclusion

Would prefer not to repeat myself, but I have to say that this is a very well designed app, with high quality finishes to it, lovely textures, feels very solid, and the swipe gestures make the home screen feel very different from the rest of the apps, it actually feels physical rather than a bunch of screens joined together by meaningless animations.

I'm actually pretty happy I could find these small details I think that could be improved, always a good exercise.

Congrats on the Path team for their great work and curious to see how much traction the service will gain.

Before jumping into the iOS bandwagon, I used Android ever since the ADP1, started paying attention to its UI about a year ago, and co-developed a Honeycomb app (UI).

To start, I'm going to sum up what I always say regarding the Android UI: there are agendas, on Google's, Mobile Networks, Manufacturers, that impact the look of the Android UI.

The system is modular to please anyone who wishes piggy back its mark onto it, tries too hard to distinguish itself via visual components like live wallpapers, pseudo futuristic aesthetics, whatever, you know the story.

I'm going to keep this really short:

In Honeycomb (and Android in general), the lack of visual affordances, or weak affordances, were one of the major issues with the OS, eg:

• almost unintelligible main navigation (back/home/menu buttons)
• weak affordance for the button widget itself

Navigation

You get there pretty easily, but wouldn't hurt to make them more obvious and any time you have to spend thinking about it is expensive to the user, as usual. (don't get me started on the need for such buttons, or buttons themselves).

Samsung and other manufacturers tried to make them more obvious:

Disregard the red highlight on the dedicated screen shot button present on all Galaxy Tab 10.1, instead direct your attention towards the first three icons.

As a reference, these are the original Android navigation icons:

(as present on the Nexus S, order and shape may vary)

Buttons

This is a simple comparison between Gingerbread and Honeycomb button widgets.

First Gingerbread:

And then Honeycomb:

The label is much more readable, but the buttons are way too blended into the rest of the UI.

Other questions arise here of course, why display this on a modal in the first place, brightness settings don't exactly require confirmation or cancel actions, neither a group of two fields - there's a slider that's visible when you disable auto-brightness, require a modal.

Ice Cream Sandwich

If you're interested on a tour through the software in ICS, watch Engadget's [video on the software of the Galaxy Nexus](http://www.engadget.com/2011/11/24 /galaxy-nexus-hspa-review/), but I gotta tell, the trend of bad UI decisions continues, many of Honeycomb's imperfections are present in ICS.

There's also a new one, this one's actually a regression and it's the way open home screen folders are displayed, previously they looked something like this:

But on ICS:

Yes, it's a modal, you have to click outside to close, single tap 'Google' to rename.

Also, this is how it looks on the home screen:

If you watch the video I mentioned earlier you'll find more dubious UI elements, like a legacy menu button that is displayed on legacy apps right to the app switcher icon in the nav area.

I would find it hard to believe these UI decisions were impacted by the agendas I mentioned earlier, they simply are thinking in a different mindset, geeky, pro users, used to deal with complex systems, recognising patterns, etc that allows them to perceive a meaning out of this interface with a minimum effort.

The subject of wether or not these UI decisions are really harmful to the rest of the users, or how obvious should your UI be, can provide for a good discussion.

Would be interesting to reach a conclusion to wether or not users will become more tech-savvy as the young grow up on this world, or if these concerns will be valid in 10 years time.