feedback wanted: developers and content managers
In a number of recent projects, we’ve wanted to help users by actually giving relevant information on how to download and install a file. This sort of thing is regularly done appropriately for high end phones (S60, Palm, Blackberry, iPhone, WinMob), because the install process and messaging is consistent for devices on the platform.
Things get more difficult for feature phones. Has the operator blocked access? Will there be a “mother may I” for each access? Can the user dismiss it? What will it say? How does the user find the downloaded content?
What I’m thinking about is a repository of instructions for users, based on class of use (such as always needs access to the web) and device. An application would detect the device and render appropriate instructions from the repository.
A download web page, for example, would give accurate instructions on how to find the specific content on the user’s device, with the instructions pulled from the repository library. As this is a key failure point in using applications, this would be helpful to both users and developers.
Please, post a reply in comments. This may be something we can work together to solve.
2 Comments »
RSS feed for comments on this post.


Absolutely! There’s enough fragmentation in trying to build an application for a mobile, and then you have to explain why it disappears once you’ve downloaded it; or why an upgrade may be “from a different source”; etc…
We could build the instructions repository keyed in to WURFL device IDs to enable easy selection.
At the moment we just have overall instructions (like http://www.nationalexpresseastcoast.com/Travel-Information/Mobile-timetable-service/) but this gets less useful as more devices are covered.
We’d be willing to work together on this and I’m sure the guys at J2ME Polish would be interested too!
Adam Cohen-Rose
Lead Developer
Kizoom Ltd.
Comment by Adam Cohen-Rose — March 16, 2008 @ 6:33 am
I have potentially the server horsepower to deploy this, and the flexibility to do so.
A Wiki style user interface seems appropriate, though the precise wiki used requires selection. From the user interface viewpoint I favour mediawiki, with all its many warts, primarily because it has a wide userbase.
The wikis I deploy are all funded by advertising, using Google as the adserver currently. This defrays the costs, and allows users free rein. An example is http://train.spottingworld.com - clear, concise, and driven by its user community - and I would see this download guide as similar. If using adverts as funding is not an option, do decide this prior to suggesting we move ahead!
Comment by Tim Trent — March 25, 2008 @ 10:39 am