While this only solves a part of the problem it immediately increases the size of the telephony application developer base (which I think is a good thing for everyone.) If a web developer can start creating mobile apps imagine the opportunities for cool new services, especially if hardware dependent telephony and GEO APIs are easily exposed?
The answer is of course under development at Mobease, with the upcoming “Mobidgets“, the revolution in mobile widgets….
The FUP maturity model: Features, Usability, Pleasure. Do not forget the Pleasure of using and app.
Deliver your promise: you cannot improve low quality app with just eye candy and visual attractivness…
Entertainment vs Enterprise type application and impact on design
FlashLite as a tool to prototype mobile UI: I totally agree, it’s one of the best tool to quickly test and geet feedback on innovative UI even if it’s not always the target technology.
Worth a read for all mobile developper/designers (and yes, In-Fusio has contributed to this nice doc!)
My remarks is that I hope that S60 Nokia UI designers will adopt this principles (especially the FUP on the Usability/Pleasure part!).
So what I like the most is this FUP concept: Features, Useability, Pleasure…Frequently, the balance is not well done in all of these. We have some great featured product, but not fun at use, or good looking one, but totally unseasable. It’s usually very hard to mix both, but some achieve to do it. A good exemple is this “discoapp” for Apple. It’s just a simple CD rom burner program, but the interface is not only very readable and clear, but fun too. A good example of well balanced mix, look at this video of what happens when a CD is being burned:
Small note to highlight this nice service: xFruits
This allows you to do different things with existing RSS feeds:
Aggregator RSS : umtiple RSS feeds transformed into one feed
RSS to Web: display in a plain web page an RSS feed
RSS to mobile: same for mobile
Post to RSS: publish through email
RSS to PDF: display a feed as a PDF document
Some grayed features, so probably comming in the next monthes are:
RSS to mail
File to RSS
The RSS aggregator and RSS to PDF are in my view the most interesting and innovative usage.
As an example, here is the xFruit result of this RSS feed as a PDF:
The result is clean and could be used as a document in some meetings for instance. This open some interesting idea of usage, especially in the enterprise…
The topic of Widgets standardisation will become a hot topic next year. We already haves so many different Widget framework based on browser (Google, Opera, NetVibes, WebWag), a few desktop based Frameworks (Yahoo!Widget and Dashboard), and now some emerging mobile widget framework (Widsets, and of course Mobidgets! ) that it’s quite sure that we can not continue into the same direction.
In this post, I will try to provide a view on the landscape of widgets in terms of interoperability (between platform) and try to explore the common part between theses framework.
First, I’ve been to “Widgipedia“, and from their FAQ, they already support these 14 platforms: (this was more than I was expecting)
Yahoo! Widgets (Windows)
Yahoo! Widgets (Mac)
Standalone Widgets (Windows);
Standalone Widgets (Mac)
Microsoft Vista Sidebar (Windows)
I assume that some of them are interoperable, especially between the mac/windows version, but it seems that it’s not always the case.
Also there are some missing components, like Netvibes, or WebWag which have their own framework, and probably Windows!Live? Flash is also a probable candidate for a Widget environment….
Mobile applications have also their own frameworks, for instance Widsets or Mobidgets
So what levels of interoperability do they have. For now, none of them are interoperables!. When you do a Google widget, than you have to recreate it for Yahoo!Widget for instance.
The positive view is to say it’s not so hard to convert a widget from one environment to the other….
Is there any hope that this will change in the near future. I am not an expert of each of these widgets framework, but we can identify two major things:
the “representation/descriptive part ” generally XML based
That’s a good start, but then you face all the little details: where are stored the user preference, how to access to some utility function, is it CSS/HTML based, etc….
So what’s next? Three options:
One of these framework become the de-facto standard, and all the others are either killed, or align to it….
A standardisation body (W3C?) take the lead on it and try to solve the problem….
Status quo, only a few widgets engines/framework are still alive and tools are created to “transcode” one widget into another?
None of this solution is perfect, but it will be interesting to see how this will evolve in the coming monthes, especially in regard of mobile who will bring new widgets framework, but who will be hardly compatible directly with other framework for many technical reasons….
I am sure that it will be an interesting topic to discuss in the upcoming “Widgets Live!” conference in SF! (which is the same day than this interesting mobile2.0 event, in SF too!)
And in the second part of this post, I will explore potential solution and direction for a common widget framework…Stay tuned.
Update: one the reader (Lindsey), pointed out this work on W3C about packaging deployment Web Application Packaging Format Requirement. This doc is a starting point, but contains a good table about various packaging format used between Google, Yahoo and others…
Sun/Laszo announced this week that they will work jointly on a new project called “Orbit”:
“Orbit” is an exciting collaborative effort between Sun Microsystems and Laszlo Systems enabling OpenLaszlo applications to run on devices supporting the Java™ Platform, Micro Edition (Java ME) application platform. This project will be delivered as part of the OpenLaszlo “Legals” multi-runtime effort, with first demos available before the end of 2006.
The promise seems a little bit big, so I excpect that exported application will have some limitation, but it is a nice idea to follow. Could this effort help to solve the “Widget fragmentation” issue?
Adobe announced today the acquisition of some technology from Actimagine, a French (yes! ) company specialized in creating technologies for mobiles.
Actimagine is made of smart people, and yes, their technology is truly optimized for mobiles devices. Their other product, Mobiclip, has been launched with big brand like SonyEricsson recently, with their MobileCinema product who allowed to haves a full movie in 256 Meg, fitting in a memory stick card.
But this announces tells also that FlashLite was not ready for mass market phone, for probably two main reasons: too big (in size) and CPU intensive… So path will probably be long to fully integrate this technology and provide the same experience than on other FlashLite implementations.
Two pictures of some really interesting concept phones. Both share the same concept of a touchscreen that fill all the phone area, so the screen can adapt to the context. That probably one of the best direction to go in…
The BenQ Black Box concept was disclosed a few weeks ago:
Looks good no? And the Nokia looks even better:
These kind of phone will be a perfect candidate for a Mobile Widget type of UI! Allowing direct access o the most important information on hte main screen, while being able to switch directly to the most relevant “layout”.
MobileZoo is a part time project done by Stephane DeLuca, one of the members of the Advanced Technology Team here at In-Fusio.
One of the initial idea (I am just over simplifiying, as there are many ideas in the air here!) was the following: instead of creating specific benchmark to provide information about handsets, or to create your own code to gather this information and store it on your server, why not provide a service for this?
The ideas is to create a small library (less than 8kb) that can be easily embedded on most (if not all) J2me application. The library than gather the maximum of information about the handset and send them to a server.
This server then maintains a database about handset capacities, supported JSR, configuration, etc…. There are multiple benefits on this approach:
developer can easily find usage of his own application. Focus on the real added value of the app, and not on this plumbing
other developer haves access to consolidated statistics about handsets capacities
marketing people will also have a visibility of handset deployed per country…
So basically, it will use the combined power of several individual small applications (typically freeware like j2memap) to create the most complete handset database available…..
We’ve just trialled it since last week with J2memap, initially for SE phones (that’s why you will see much more SE than Nokia) and now for most of the handsets. The results are quite interesting:
First, the most used handset, is without any surprise, the SE K750. But just after is the K700, a quite old model know but still heavily enjoyed by many users.
Then, the W800i, W810, etc….
Of course, some Java Vending Machine haves some of this feature built in, but none of them offer such service for third party, and expose this detailed information about usage both for the application user, and for the community….