So, the interface will require a trigger, to know when to listen to commands, this is an interesting challenge.

On many other interface types, there is always a feedback mechanism, to assure the user the action was completed, gesture was recognised, etc

With thought control, what would be the feedback mechanism? Sound? Will there be one? Will the person trust the system blindly and just fire away actions?

We're talking about abstract actions here, moving an arm provides direct visual and perhaps sensor feedback, but taking a picture, sending a text is a bit different.

If feedback come into play, thought interfaces will be, at least initially disruptive, you won't need to move, but you will need to concentrate in it and friction will perhaps be enough to distract you from your main task.

Another use case for thought interfaces is the passive monitoring of the users thoughts, thinking about how good yesterday's Affogato was? Well, Facethought will let your friends know you'd love them to bring you one while you're inside Small Batch Coffee.

Cultural barriers are obvious with this latest option, people won't feel comfortable with this kind of urges being shared and perhaps don't want to manage them because of their nature.

Another thing to consider is a hybrid interface, technology like Disney Research' Touché could provide a way to reliably denote intention in a very frictionless way such as touching your chest twice, blinking - which perhaps can be easily identified by the thought interface as well.

So, here's to imagination.

Our brains are very lazy things, unless we we exercise them, learn, adaptation is going to be harder and harder as it gets used to the easy way. In our industry, we can't afford going through the easiest path, we need to be disruptive, we need to push forward.

Grey Goo Machine

Our brain is constantly trying to optimise every task we assign to it.

It adapts, it learns.

For a certain task, the cognitive effort is reduced the more times we perform it, but the effort is never null.

The learning process has many intricacies, part of them is the frustration of not being able to achieve results as fast as method X - previously learned and stored, is able to. Your brain doesn't like frustration so it will always try to pick the shortest known viable path to task completion.

This path finding process has a tendency to be optimised as well, so, if it can be skipped, it will be, and it'll use, as mentioned above, the shortest known path.

Your brain just wants the reward of achieving a task as fast as possible, no matter what.

Think games.

Quick gratification is essential to the success of a mainstream game (1).

With that also in mind, let's talk web development and developers in general.

Everybody loves automation, the effort to reward ratio goes off the charts when it comes to automation tools, you're able to perform thousands of tasks with a single or no command, and that's awesome, but has its perils as well.

I'll cover that in a future post, for now let's just talk about quality.

Change

Our industry moves faster than anything else out there, it has unique interactions, unique communities, unique metabolism.

It's intrinsically connected to hardware and software industries, and as they move so does the web.

Form factors, browsers and screen hardware changed our approach to delivering our product: the experience, we package it up in a future friendly way as agnostic as possible to how it will be accessed, made possible by the software we have at our disposal.

This new approach provides a better experience to the end user and isn't entirely necessary as a general rule.

There's nothing like it, to my knowledge in other industry: our tools changed, our process changed, our product changed, and it will change again very soon.

On the human level, many of our previously optimised tasks will have to be thrown away, your brain won't like it because it doesn't always understand the motives - originated in the higher cognitive areas, to do it.

I believe intelligence - in it's classical definition, has nothing to do with it. I believe, however, in a definition of intelligence where this ability to adapt is key.

I also believe the more specialised you are, the harder it will be or you to adapt.

"More addicted to known paths your brain will be." - Mr. Yo.

There's a sensitive balance, a sweet spot between specialisation and lack of it.

I've learned from experience how genuinely amazing innocence and naiveness can be.

One might say these are qualities essential in a team, and companies where skill and experience is the only aspect sought after in an individual are inherently poisonous to innovation, new approaches, new perspectives. Although, we're not talking in Boolean terms here.

Much more could be said about this topic, but let's talk about Quality.

Quality

I am of the opinion that aiming high is essential for one to remain relevant in this industry for multiple reasons:

• you'll have fun with what you can achieve with new technologies
• you'll prevent your brain from going numb
• your work will benefit more people and will be less likely to disappoint
• in the real life, you don't create in vacuum, there will be external factors pushing down the quality of your work, so aim high to prevent negative return - be careful with this statement, aiming high doesn't mean perfection or quantity, it's a target where the quality is in perfect balance with results.

Aim high, remain path-agnostic, reward yourself but also question yourself.

Love what you do, it's the best way to remain relevant, to stay hungry, stay foolish.

Enjoy.

Footnotes

(1) the greater the reward, the more people will invest into achieving it. Based on observation, I've noticed people have a preference for smaller, more frequent rewards though.

• What will Twitter, Clear, Facebook, the Lock Screen feel like?
• What will be the impact of high quality haptic feedback in the way we perceive and use our phones?
• Will the rest of the technology fall behind and fail to provide a full and convincing experience?
• What will be the impact on the UI of the application, the size of the buttons, represented textures, will there be a preferred texture?
• Will you be able to identify certain groups of apps by their predominant texture?

Imagine the ways we could explore that feature: increase the friction of a list when it reaches a limit.

God I can't wait to try that out.

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 reasoning 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.