[Freedombox-discuss] CCC Meeting Notes

[Jonas Smedegaard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110819/0aea62e0/attachment.pgp>