The iPad is an appliance not a computer & you should be happy about that

Picture this.





You've spent ten straight hours hunched over the laptop/desktop at work, hammering out code/composing a TPS report or whatever it is that you do at work that involves the use of a computer.





You've reached home. Now, you settle into the couch & want some relief. You pick up your home laptop/netbook to read a Dilbert comic strip to see the humor in your incredibly obtuse manager or the nefarious cost cutting.





Instead, you see the Virus Scanner reporting 3 new viruses found. Or that your disk has run out of space & needs defragmenting. Or, there are 16 new updates in the OS & you need to patch the OS. Now.





Tell me truthfully, do you look forward to this?





You maybe a Unix hacker by the day, but hey, this is entertainment! Do you tinker with the frequency bands in your TV everyday? Do you try to optimize the sound bitrate in your stereo? No? 





I've been using an iPod Touch since November 2009. I've been using a home desktop & an office laptop during the same period. When I want to play a racing game or quickly check my email on my iPod, I have yet to face a scenario like the one mentioned above.





And I'm glad about that, however much I may love tinkering with technology.





So, if the iPad is a 'dumb' device that doesn't allow installing software and isn't letting you hack away at it's internals, why bother? It's a radio, a TV, a car. Use it for a few hours and forget about it. 





Enough said.

My take on the "User Experience research tools, IA case studies, and overview of London UX scene" @ Yahoo! Bangalore last week

As an aside, we had difficulty entering the conference room where the talk was on. This is so because the organizer(s) didn't mention a contact person name/venue details. You can't pick faults with free & interesting talks, but this would greatly improve the UX of any further talks :-)

To the talk now. The central point of the talk(s) were the cultural differences between European & Asian audiences & therefore the impact of these subtleties on UX design. UX is User eXperience, for the uninitiated.

What I picked from the talk - 

- Details of how designers design. HINT: They create Personas.

- Details on how large companies, e.g. Vodafone address cultural subtleties so their Product people, sitting in one geography can design products & services for everyone. 

Personas

Dr. Anxo Cereijo Roibás described how designers go about designing. They create Personas. They collect a great deal of information about people using their product. Then they gradually group all of this into a Persona, name that Persona & use a limited collection of Personas to design. This helps focusing the design to the needs to specific people rather than specific spreadsheets.

Ethnographic Research for UX

Vodafone picked three countries - Egypt, India & South Africa to gauge user behavior w.r.t to new services. 

They had two sets of people in mind. One, the top & middle of the pyramid. English speaking users with smartphones. The objective was to test user expectations for the use of social networking applications using mobile phones.

They had two types of tasks. One, where they had SMS's sent to the users with requests to respond immediately with information - Where are you? What do you see? How do you feel about that? 

The test users sent back responses either through SMS or through MMS (if the answer required a photo/video).

The other type of tasks were more deliberate & needed planning. 

One interesting thing they came up with, with this research is the concept of a map in the mind of the Indian user. It's more to do with a general lay of the land & a bunch of landmarks, rather than precise directions like you see in Google Maps.


Surprise, surprise. Google Maps this week released an update to Google Maps for India, based on this very concept! http://googleblog.blogspot.com/2009/12/go-thataway-google-maps-india-learns-to.html


The bottom-of-the-pyramid users were administered the tasks by local researchers, since many had not even heard of a mobile phone. 


Some interesting findings:

• When asked how they would create a profile for themselves, that other people could see, most came up with a design that looked like a Facebook profile! Complete with a photo at the top corner.
• A lot of people wanted a 'service' through which they could list the skills they had, so others could find them and give them work to do. There seems to be a gaping hole in the Rural Job Classifieds market!
• A lot of people indicated they would like some way to maintain bank accounts using mobile phones, given that it would be hard/impossible to do so in any other way.

So, all in all, this was a nice session with some key learning. Looking forward to more. Bravo! Yahoo! for doing this!

Google Chrome OS - All the links you could possibly want

• Introducing Google Chrome OS [Official Google Blog]
• What does Google Chrome OS look like? [Youtube, official Google Chrome Channel]
• 5 Things Google Chrome OS will do, for your netbook [Wired Magazine]
• Will Google Chrome OS kill Windows? [Mashable]
• What Google Chrome OS means for netbooks, and why M$FT needs to be scared?[Crunchgear]
• Try Google Chrome OS yourself. Now. [Techcrunch]
• Google Chrome OS - The VMWare Image [gdgt]
• Gizmodo weigns in on Google Chrome OS [Gizmodo]
• Engadget weighs in on Google Chrome OS [Engadget]
• Ditch your hard drive, the future is the web [Wired Magazine]

OpenSocial In The Enterprise

This is a short post on some very long discussions that we(me & Rajvel) had on how OpenSocial fits in the Enterprise world.

First, here are the resources we referred to -

The OpenSocial specification

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Specification.html

The OpenSocial Gadgets specification

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html

To start with I'd like to debunk the 'Portability of Gadgets across containers' concept for OpenSocial containers in the Enterprise world.

Assertion: Outside of pure social networking, portability of Open Social Widgets has no meaning. Portability only comes into play when using Open Social Javascript API's to get People, Friends, etc. This ensures a social networking widget written using OpenSocial features of the container will run on any other OpenSocial container & more importantly work in the context of that container without any code change.

In the enterprise world, where it is more likely that each provider will create non-standard extensions/features to the container to solve their business case, portability has no meaning at all. We're not after OpenSocial API's. We're mostly after a platform to enable widget developers.

Packaging: The Hidden Benefit?

Moving on, according to us, one of the hidden benefits of the use of an OpenSocial container in the enterprise is - Packaging.

As per the OpenSocial Gadget specification, there are two distinct delivery mechanisms for a OpenSocial gadget. The more often used one, where the gadget is defined in the of the Gadget XML & is processed by the container.

The other where one provides a URL to the content (HTML + CSS + Javascript) somewhere. In this case interestingly, the responsibility of packaging & hosting the application/gadget is one that the Gadget Developer must take on. The container simply uses the content from the URL, wraps it in an IFRAME and passes it on.

Constrast this with the pure OpenSocial Gadget case where the Gadget Developer knows the target container & it's (probably proprietary features). He develops & tests his gadget against this container in his test setup. Thereafter, he simply shares with the world one XML file and everything else is gloriously managed by the container! How do you like that for convenience? :-)

This also brings in a counter-argument to our assertion of Portability of Gadgets across containers being nonsensical in the enterprise context. But we would like to point out that, while the Gadget Developer relies on the portability of his gadget & therefore is comfortable in publishing the XML confident that it will run on a container that is similar to his, the gadget is NOT portable across ANY OpenSocial container in the way that true social gadgets using the core OpenSocial API's are.

You may want to think of the analogy of a Java programmer who develops an application on an X86 machine, confident (at least reasonably) that this same program will run just fine on a Mainframe that has a Java VM.

Exposing Jazz Services as Javascript API's

This is perhaps the obvious next step in the thought process. Think of a Jazz Open Social container, that has implemented a Jazz Foundation feature that exposes all of the JFS services as Javascript API's.

Is that a good idea? Or worthwhile?

Or would it be better to just ask gadgets/widgets to simply use the existing REST API's?

I can only argue that it would be convenient for widget developers if all the complexity of making the REST requests were abstracted away.

This would be like the Jazz Java SDK that is available today that does this on the server side.

The question of why we should not just provide this as a simple Javascript library comes up again. Let the widget developer use the library in whatever way they seem fit & deal with the packaging.

But then you miss out on the benefits of the pure HTML deliver of OpenSocial, as argued above. So we think this is a good idea too. It would enable rapid development of widgets for the Jazz platform, using the power of the Jazz services to any one using the JTS (which would probably have a OpenSocial container bundled in & have special features implemented).

PonderPoint #2: ExRel with OSLC

This is a rather technical one. My thoughts on how ExRel's as they exist in Webtop could be done using basic OSLC (Open Services For Lifecycle Collaboration) concepts.

My first argument is that ExRel's in Webtop are essentially a correlation mechanism. The idea is to say some object, say a Model Element, is related to another object, say a Work Item. The intention is never to understand the underlying data at the other end of a link.

My second argument is that this fits with the Level 1 definition of OSLC where you can link objects simply by using URL's given that each resource/object has a URL.

My third argument is that each side of the ExRel must store the URL of the other side. Now that brings up a question of who stores all these mappings of objects -> related object URL's?

My argument here is that given that we're trying to enable Collaborative ALM here, and avoid brittle point to point integrations, we cannot ask tools to store this data. 

The counter argument that just occurred to me when typing this out, is that if each tool were to store objects -> related object URL's mapping then we could have ALM without really using any Jazz services simply relying on REST. That's really a Level 1 kind of idea.

The other way, which I find more appropriate is this. Given that we're speaking of solving ALM, we're definitely talking about more than one tool. So if we're linking objects it must be from the context of a new application (such as RTC/Webtop). Therefore, the objects -> related object URL's mapping storage and maintenance should be done by that application using several Jazz Foundation Services. 

We'd obviously store mappings both ways to enable navigation to related objects both ways given that ExRel's are not directional.

Classifying Twitter

I mean to expand on this later. But I was wondering how to 'label' Twitter?

I was hearing the TWiT podcast (http://twit.tv/twit)

which is an excellent podcast by the way and as is customary, there's a social media update from Leo Laporte.

Here's the first update. Lance Armstrong, avid twitterer, refused to speak to the press and instead updated his Twitter and initmated fans about a broken arm. Is this bypassing of conventional media? Is Twitter the ultimate ether, where anyone with a radio station can broadcast news? And your twitter account is exactly a mechanism to do that?

http://www.google.com/hostednews/afp/article/ALeqM5hqaYvaKXPG6ygYt1V_VSjpj5xz1w

Here's the second story, about corporate use of Twitter.

http://mashable.com/2009/05/21/twares/

An airline bypassing all conventional media for advertising vis-a-vis : radio, tv, print media, the traditional internet web ad's and going straight to the users.

Minute Repeater

Aimlessly browsing through Rediff.com I came across a slide show of the world's most expensive watches. And a feature that they all had was Minute Repeater. Naturally curious, I went and looked this up in the Wiki and this is what I found.

A repeater is a complication in a mechanical watch or clock that audibly chimes the hours and often minutes at the press of a button. There are many types of repeater, from the simple repeater which merely strikes the number of hours, to the minute repeater which chimes the time down to the minute, using separate tones for hours, quarter hours, and minutes. They originated before widespread artificial illumination, to allow the time to be determined in the dark,^[1] and were also used by the visually impaired.

Here are two examples -

Michael Phelps Ka Kachha

Is Michael Phelps the greatest Olympian? Or is his Speedo LZR undie the fastest undie to ever dip into a swimming pool?

Found this article quite informative on the topic, especially the conclusion, which is quite hillarious.

Perhaps they could go back to competing nude as they did at the original games. It would make the swimming and track events more interesting but, on the other hand, the weightlifting would be positively terrifying. Maybe that’s not such a good idea after all.

Read the rest here.