On 11-08-19 at 03:22am, Martin Dluhos wrote: > On 08/15/2011 03:40 PM, Isaac Wilder wrote:
> > We also discussed UI, stressing its paramount importance to the > > success or failure of the endeavor. The idea of having the user > > configure and interface with the box via chatt (XMPP chat) was > > suggested. There's also always the fallback position of a web GUI. > > Still, many felt that the chat idea has great potential. > > I do not quite understand the idea of configuring and interfacing with > FBX via XMPP chat. How do you envision such process? It seems to me > that web interface might be more user friendly (which is very > important for FBX) since people are already familiar with it. We want > the learning curve to be as gentle as possible. Sometimes the more userfriendly is to present choices in a familiar way. Other times the more userfriendly is to not present choices at all. We need not wait for user experience (UX) designers to start work on reducing the amount of choices needed to present to our users. And it is helpful for the task of reducing choices, that presenting choice is difficult. Keeping open how the interface will look and feel helps us technicians to reduce more, and also avoids creating unneeded limitations for UX designers. I therefore recommend we think in multiple "limited" config interfaces! *** How would you want to setup a service when your interface to doing so is an interactive dialog with a bot on Jabber? Or if it was a dialpad with 12 buttons on a phone handset? We probably all tried interacting with an online phone service in the style of "For sales, press 1; for tech support, press 2, etc..." and experienced that more than 3-4 options to a choice is annoying, and too many choices makes you feel like in a maze. We should expect our users to feel alienated by most of the choices we at first find crucial to ask. We should try very VERY hard to reduce the amount of needed choices to present at all. One way to reduce presentation of choice is to infer choices from actions. A daemon could try make sense of the kind of files stored on a storage service, and if a bunch of music files were added could trigger the Jabber bot to suggest starting a jukebox service. If a user engages in public activities like tweeting or blogging and also uses the jukebox, the bot could suggest to advertise the jukebox activities among friends. Hints from friends' jukebox activities could be used to improve the auto-DJ (adding new tunes when none is added explicitly - see the Debian package mpd-sima for a concrete example), and more generally could improve knowledge on how the user is related to friends - some but not all of my friends I share musical interests with, some I chat with frequently, some I am related to by blood, etc. - all of that is knowledge that can be slowly inferred by activities, and improve the sensibility of suggestions made by the bot to its user. Something like Nepomuk (which unfortunately is entangled with KDE libs). Here is an inspirational article about (use of) Nepomuk at LWN.net: http://lwn.net/SubscriberLink/455073/9b37287defc56dee/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
