Our mobiles screens are getting everyday bigger and brighter, my Treo, for instance, is capable of transforming itself in a light in not daylight contexts. This made me think of many ideas around the context of using the mobile display as a short range communication tool. Quite interesting the fact that it is meant to be for very long range interactions.
There are also situations in public where speaking becomes odd and also shyness can be an obstacle. If we consider that nowadays our environment is getting crowded of flat screen / projectors, why not to use our own?

In this first implementation the user can use the display to show text messages he writes, not sms. The size of the text of course depends on the display size. The user can then change the text speed if necessary. As you can see it’s a pretty banal application, but it could be a good start to investigate on the usages we could do of those big displays.

Following two demo videos, unfortunately not a proper scenario, I’ll leave it to your imagination (someone trying to approach a gril in a club, for instance, or suggesting something private to a friend in public spaces).

Due for technical limitations of the platform I developed the first prototype, many of my ideas are not yet implemented, but hopefully I’ll be able to do it soon or later (if anyone is interested on helping me, it will be of course welcome).

At the moment it has been developed a PalmOS version, thanks to the fundamental work from Jagat N. Mahapatra, and a FlashLite 2.x version, that I did by myself. At the moment I’m considering the eventuality of developing a J2ME version (that would make it much more accessible).

Any feedback is welcome.

When this autumn began I decided as indoor spare time activity (everyone knows how sad winter in London is) to improve my poor C++ maybe applying it to hand held devices. I had some applications in mind that I wanted to create and as Palm Treo owner, and in need of multimedia functionalities, with J2ME it wouldn’t have been straight forward anyway.

After my computers have been stolen (and thus lost the source of many experiments) and found out that OOP in PalmOS is not that recommended, after many months of not exiting results I ended up looking for a technical partner for PalmOS development. At that speed I would have probably delivered the applications way after PalmOS was extinct.

Of course my interest was far from producing final and refined software, i wanted mainly to prototype some ideas and it’s clear C is not the most recommended platform for prototyping, but due to my learning interest and poor testing devices availability I gave it a go.

Luckily I recently bought a second hand Nokia N70 where I could easily install FlashLite 2.1 and very easily prototype the applications with limited hardware access. In the same device I will be probably be able to use in Java at least some multimedia functionalities for more complex prototypes.

I’ll post soon the first concept, stay tuned!

It’s getting even more common to deal with clients that need an accessible site (this happens in general with big corporates or government institutions). An HTML based solution is always the best choice for this, also because from the tests I did so far there are too many variables to permit to a screenreader to read and browse Flash content. The problem is when the client wants also something engaging and appealing, for this reason JavaScript can’t be compared to Flash: a solution like that would require much more time due to many compatibility issues.
Taking inspiration from the technique used by sIFR (Rich Accessible Typography for the Masses), I thought to replace a HTML chart with a Flash applet where I pass as data the code of the initial chart itself. We are defintely talking about much more complex data then simple text, and for this reason they have to be structured. XML, of course, is the best way, so I instantly decided that the initial chart should have to be in XHTML.

Not being an Accessibility expert, the first thing I did was to google for an accessible XHTML chart. I found then this example, wonderful for its semplicity but that, I have to admit, required small modifications, that I tried to fix as much as I could, to be as mush accessible that possible.
I thought it was enough to get the XHTML code with the innerHTML property of the element containing the chart and passing it straight to the SWF in its FlashVars parameter, but instead the typical browser issues came up. For instance, the innerHTML property, even if the page is in XHTML, returns always HTML code and — without closing tags like BR and IMG — it breaks unavoidably the XML formatting. Netscape based browsers embed a serializer (XMLSerializer class) that does a wonderful job, but we can’t renunce to IE compatibility, at least with Windows. The remaining solution is to convert the HTML coming from innerHTML to XHTML. To build this converter have been crucial the Regular Expressions (regexp). Being a very customized solution, so where the used tags are known, it has been enough a relatively simple regexp that so can’t be definitely considered very consistent, if we imagine, for instance, the eventual usage for new tags added later on.
This is the final result that, I want to clarify, rests an example of a possible technique and so very far from a final solution adaptable automatically to any context.

By the way I hope someone can take inspiration for this approach too and maybe investigate more on the potentialities. Here are the source files of all the experiment.