[Freedombox-discuss] CCC Meeting Notes
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>
Reply to: