User Experience

[etoile-3]

Yesterday, Quentin, Eric and I had a discussion on SILC about what the  
user experience (and, at some level, the developer experience) should  
look like under Etoile when interacting with Documents. Rather than  
debating the merits of each of our points, I'd rather just ask a  
series of questions that I hope gets to everyone's vision of the  
interaction model.

1. How does a user create a new (generic) Document? What menu steps  
must they walk through?

2. Assuming a user wants a specific Document type (say, a vector art  
document that can be easily converted to SVG), what steps must they  
walk through to get their original generic Document into a format  
easily converted to that specific type?

3. If a user wants to then edit that (now SVG-friendly) Document, how  
do they launch the proper tools/palettes?

4. When in editing mode, what app should be represented in the  
system's Menu bar?

5. When a user closes (hides/puts away) the current Document, what  
methods can they use to reopen it?

6. What happens when a user selects on a specific object (a bar graph,  
for example) within a compound Document? What happens when a user  
wants to edit that object? How do they initiate that process?

7. How does a user manage the various Services on their system?  
Through what type of UI?

8. How are those Services organized?

9. How does a user get new Services on their system?


Getting answers to these questions should help with some of the  
specifics of how applications work and are integrated in Etoile.  
Thanks in advance for contributions.


J.



_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Eric Wasylishen-2]

Hey Jesse, I think this is a great idea.

I have one to add:

10. From the user's perspective, what form will photo and music
management take? What sort of interaction would a user perform to
reach his music library?

On Tue, May 5, 2009 at 8:49 AM, Jesse Ross <etoile@...> wrote:

> Yesterday, Quentin, Eric and I had a discussion on SILC about what the
> user experience (and, at some level, the developer experience) should
> look like under Etoile when interacting with Documents. Rather than
> debating the merits of each of our points, I'd rather just ask a
> series of questions that I hope gets to everyone's vision of the
> interaction model.
>
> 1. How does a user create a new (generic) Document? What menu steps
> must they walk through?
>
> 2. Assuming a user wants a specific Document type (say, a vector art
> document that can be easily converted to SVG), what steps must they
> walk through to get their original generic Document into a format
> easily converted to that specific type?
>
> 3. If a user wants to then edit that (now SVG-friendly) Document, how
> do they launch the proper tools/palettes?
>
> 4. When in editing mode, what app should be represented in the
> system's Menu bar?
>
> 5. When a user closes (hides/puts away) the current Document, what
> methods can they use to reopen it?
>
> 6. What happens when a user selects on a specific object (a bar graph,
> for example) within a compound Document? What happens when a user
> wants to edit that object? How do they initiate that process?
>
> 7. How does a user manage the various Services on their system?
> Through what type of UI?
>
> 8. How are those Services organized?
>
> 9. How does a user get new Services on their system?
>
>
> Getting answers to these questions should help with some of the
> specifics of how applications work and are integrated in Etoile.
> Thanks in advance for contributions.
>
>
> J.
>
>
>
> _______________________________________________
> Etoile-discuss mailing list
> Etoile-discuss@...
> https://mail.gna.org/listinfo/etoile-discuss
>

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Sourav K. Mandal]

On Tue, 2009-05-05 at 16:59 -0600, Eric Wasylishen wrote:
> Hey Jesse, I think this is a great idea.
>
> I have one to add:
>
> 10. From the user's perspective, what form will photo and music
> management take? What sort of interaction would a user perform to
> reach his music library?

Speaking from the peanut gallery here, this question could be
generalized:  many documents on a user's desktop are not edited, but
simply downloaded and read.  What does the workflow look like when you
aren't "working" on something per se?

Many professional tools seem to follow the pattern laid out by Jesse in
his email.  For example, Pro/Engineer asks you what kind of generic
project you would like to start working on, then the contents of menus
and palettes afterward depend on the project type.  To get to a specific
format you can exchange with non-Pro/E software, you use an export
service through one of the menus.  (Saving and accessing projects is
done using the operating system's filesystem.)

However, multimedia seems to follow a completely different model:  one
has "collections" which are managed, displayed or transmitted.

How to reconcile these two flows?



_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[etoile-3]

> However, multimedia seems to follow a completely different model:  one
> has "collections" which are managed, displayed or transmitted.
>
> How to reconcile these two flows?


I think there are actually three types of UI-based applications that  
need to be dealt with:

  - Collection managers
  - Document creators/viewers
  - Tasks/widgets

I think my sense, and the approach we seem to be taking, is that  
managers, like iTunes or iPhoto, are just specialized file browsers/
managers. So, they can be represented with some custom views on our  
file/object manager data. This way, developers wouldn't have to  
create a full app just to browse and manage music. Instead, they  
would just define a UI and some custom methods for displaying and  
interacting with that data in a sensible way, and provide that as a  
"plug-in" on our file/object manager. This approach would even work  
for things that a user maybe doesn't think of as a manager, such as a  
calendar application -- at its heart, it's just a manager for  
calendar events. The tricky part of all of this is answering the  
question, "How does the user open up their music library?" Even  
though it's just a custom view on some data, is it still its own  
application? Or can any file/object manager window just be  
transformed into a music player?

Document creators/viewers are conceptually well-understood, but, as  
per my earlier questions, we need to develop their UI model a bit  
more thoroughly.

Tasks/widgets are things like calculators, notifiers, feed readers,  
language translators, weather updaters, and system reporters  
(processor load, RAM usage, etc). Most of these should be developed  
as Services, either with or without a UI. These should not need to  
have access to the menubar (just as widgets and menubar applets on OS  
X don't change what application shows up in the menubar when you  
interact with them), and so don't affect how the user interacts with  
the system in any meaningful way for this discussion.

Does that seem logical?

J.





_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[brian muhumuza]

Here are a couple of illustrations to answer the questions in the most
simple way i could figure.

On Wed, May 6, 2009 at 1:59 AM, Eric Wasylishen <ewasylishen@...> wrote:

> Hey Jesse, I think this is a great idea.
>
> I have one to add:
>
> 10. From the user's perspective, what form will photo and music
> management take? What sort of interaction would a user perform to
> reach his music library?
>
> On Tue, May 5, 2009 at 8:49 AM, Jesse Ross <etoile@...> wrote:
>> Yesterday, Quentin, Eric and I had a discussion on SILC about what the
>> user experience (and, at some level, the developer experience) should
>> look like under Etoile when interacting with Documents. Rather than
>> debating the merits of each of our points, I'd rather just ask a
>> series of questions that I hope gets to everyone's vision of the
>> interaction model.
>>
>> 1. How does a user create a new (generic) Document? What menu steps
>> must they walk through?
>>
>> 2. Assuming a user wants a specific Document type (say, a vector art
>> document that can be easily converted to SVG), what steps must they
>> walk through to get their original generic Document into a format
>> easily converted to that specific type?
>>
>> 3. If a user wants to then edit that (now SVG-friendly) Document, how
>> do they launch the proper tools/palettes?
>>
>> 4. When in editing mode, what app should be represented in the
>> system's Menu bar?
>>
>> 5. When a user closes (hides/puts away) the current Document, what
>> methods can they use to reopen it?
>>
>> 6. What happens when a user selects on a specific object (a bar graph,
>> for example) within a compound Document? What happens when a user
>> wants to edit that object? How do they initiate that process?
>>
>> 7. How does a user manage the various Services on their system?
>> Through what type of UI?
>>
>> 8. How are those Services organized?
>>
>> 9. How does a user get new Services on their system?
>>
>>
>> Getting answers to these questions should help with some of the
>> specifics of how applications work and are integrated in Etoile.
>> Thanks in advance for contributions.
>>
>>
>> J.
>>
>>
>>
>> _______________________________________________
>> Etoile-discuss mailing list
>> Etoile-discuss@...
>> https://mail.gna.org/listinfo/etoile-discuss
>>
>
> _______________________________________________
> Etoile-discuss mailing list
> Etoile-discuss@...
> https://mail.gna.org/listinfo/etoile-discuss
>

--
//MB


_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Sourav K. Mandal]

On Wed, 2009-05-06 at 17:30 +0300, brian muhumuza wrote:
> Here are a couple of illustrations to answer the questions in the most
> simple way i could figure.

Brian, this looks fantastic!

Looking at your past posts on this list, it seems that you have a
coherent vision of how the desktop could operate.  Perhaps you could
integrate *all* these into a single presentation?  A document like this
on the website would go along way towards communicating to others what
Etoile is trying to achieve ...

Here's one interesting set of illustrations I found:

http://brian.muhumuza.googlepages.com/working_with_objects.html


Cheers,

Sourav



_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[etoile-3]

>> Here are a couple of illustrations to answer the questions in the  
>> most
>> simple way i could figure.
>
> Brian, this looks fantastic!
>
> Looking at your past posts on this list, it seems that you have a
> coherent vision of how the desktop could operate.

Yep -- I think Brian's vision is pretty close to what we want to do. I  
would support adopting his general outline, with maybe a few  
modifications:

  - I think in addition to the Template-style interface in #2, we  
should add an setting to let new Documents start out as a specific  
type of file, whether that is plain text or rich text or vector image  
or whatever. This could also be a per-Project setting.

  - It may be preferable to have tools live as palettes outside of the  
editing window. I think this would be easier from a programming  
perspective as well.

  - For #6, do we want to allow in-place editing?

  - For #10, do we see any reason for having a unified photo or music  
manager, a la iPhoto or iTunes? Or, can we somehow transform a Project  
into that, so that the Project will contain all the albums/playlists,  
and we can tell the Project to just show all pictures or play all songs?


Thanks again, Brian! Nice work!


J.



_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[brian muhumuza]

On Wed, May 6, 2009 at 5:57 PM, Sourav K. Mandal
<sourav.mandal@...> wrote:
> On Wed, 2009-05-06 at 17:30 +0300, brian muhumuza wrote:
>> Here are a couple of illustrations to answer the questions in the most
>> simple way i could figure.
>
> Brian, this looks fantastic!

thanks Sourav

>
> Looking at your past posts on this list, it seems that you have a
> coherent vision of how the desktop could operate.  Perhaps you could
> integrate *all* these into a single presentation?  A document like this
> on the website would go along way towards communicating to others what
> Etoile is trying to achieve ...

Well, that's not a problem for me. Every one would need to agree to
the interaction especially the Étoilé developers.

>
> Here's one interesting set of illustrations I found:
>
> http://brian.muhumuza.googlepages.com/working_with_objects.html

i did those when my mind was still running wild with the idea. i have
simplified most of the ideas on there.

>
>
> Cheers,
>
> Sourav
>
>
>
> _______________________________________________
> Etoile-discuss mailing list
> Etoile-discuss@...
> https://mail.gna.org/listinfo/etoile-discuss
>

--
//MB

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Sourav K. Mandal]

>   - I think in addition to the Template-style interface in #2, we  
> should add an setting to let new Documents start out as a specific  
> type of file, whether that is plain text or rich text or vector image  
> or whatever. This could also be a per-Project setting.

As long as it's clear what the default is set to, and how to change it,
I think this is a fine way to boost working pace.  There are many tasks
where there objects being created are primarily of one type ...

>   - For #10, do we see any reason for having a unified photo or music  
> manager, a la iPhoto or iTunes? Or, can we somehow transform a Project  
> into that, so that the Project will contain all the albums/playlists,  
> and we can tell the Project to just show all pictures or play all songs?

By "unified" do you mean a single app to view all songs or photos?  That
seems to run against the spirit of Etoile; OTOH, songs and photos are
the kinds of things that you might like to have all in one place.

Perhaps one could instantiate collections by selecting them with a mouse
and using the context menu.  These collections could be
viewed/manipulated using an object browser service.

These collections may be strewn across various projects, but the object
browser can search for them and the user can organize them any way he or
she likes: flat in one-project, in sub-projects, or just all over the
place.

Do I misunderstand you?



_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[brian muhumuza]

After rethinking project management from the last mockup i made
(http://brian.muhumuza.googlepages.com/working_with_objects.html),
here's how i look at it now (image attached).

On Wed, May 6, 2009 at 11:17 AM, Sourav K. Mandal
<sourav.mandal@...> wrote:

> On Tue, 2009-05-05 at 16:59 -0600, Eric Wasylishen wrote:
>> Hey Jesse, I think this is a great idea.
>>
>> I have one to add:
>>
>> 10. From the user's perspective, what form will photo and music
>> management take? What sort of interaction would a user perform to
>> reach his music library?
>
> Speaking from the peanut gallery here, this question could be
> generalized:  many documents on a user's desktop are not edited, but
> simply downloaded and read.  What does the workflow look like when you
> aren't "working" on something per se?
>
> Many professional tools seem to follow the pattern laid out by Jesse in
> his email.  For example, Pro/Engineer asks you what kind of generic
> project you would like to start working on, then the contents of menus
> and palettes afterward depend on the project type.  To get to a specific
> format you can exchange with non-Pro/E software, you use an export
> service through one of the menus.  (Saving and accessing projects is
> done using the operating system's filesystem.)
>
> However, multimedia seems to follow a completely different model:  one
> has "collections" which are managed, displayed or transmitted.
>
> How to reconcile these two flows?
>
>
>
> _______________________________________________
> Etoile-discuss mailing list
> Etoile-discuss@...
> https://mail.gna.org/listinfo/etoile-discuss
>

--
//MB


_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Sourav K. Mandal]

On Sat, 2009-05-09 at 14:14 +0300, brian muhumuza wrote:
> After rethinking project management from the last mockup i made
> (http://brian.muhumuza.googlepages.com/working_with_objects.html),
> here's how i look at it now (image attached).

Brian, thanks for this new mockup.

I wonder if having a default workspace named "Desktop" is a step
backward -- it will become a dumping ground for most users.  The beauty
of the document+project model is that it blends organization with
workflow.  Users will go along with it, and magically find themselves
more organized at a later date than they might be otherwise  :)  Users
who would be organized anyway would appreciate the efficiency of this
model.

Also, your description of "Desktop" hints at it being application-driven
rather than document-driven -- is this accurate, or am I misreading?


Best,

Sourav




_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[brian muhumuza]

On Sun, May 10, 2009 at 11:53 AM, Sourav K. Mandal
<sourav.mandal@...> wrote:

> On Sat, 2009-05-09 at 14:14 +0300, brian muhumuza wrote:
>> After rethinking project management from the last mockup i made
>> (http://brian.muhumuza.googlepages.com/working_with_objects.html),
>> here's how i look at it now (image attached).
>
> Brian, thanks for this new mockup.
>
> I wonder if having a default workspace named "Desktop" is a step
> backward -- it will become a dumping ground for most users.  The beauty
> of the document+project model is that it blends organization with
> workflow.  Users will go along with it, and magically find themselves
> more organized at a later date than they might be otherwise  :)  Users

i think i see how it would be a dumping ground. the issue i was trying
to address is that of creating a system that forces a user to work
like a machine.

> who would be organized anyway would appreciate the efficiency of this
> model.
>
> Also, your description of "Desktop" hints at it being application-driven
> rather than document-driven -- is this accurate, or am I misreading?
>
>

what i meant to show was that the "Desktop" is a project too but a
user doesn't have to create it first, it is always there. otherwise
documents behave exactly as i described in the first mock up.

where u see a window with a tool bar, etc i used it as an example.

> Best,
>
> Sourav
>
>
>
>
> _______________________________________________
> Etoile-discuss mailing list
> Etoile-discuss@...
> https://mail.gna.org/listinfo/etoile-discuss
>

--
//MB

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[Sebastian Nowicki-3]

On May 6, 2009, at 5:20 PM, Jesse Ross wrote:

>  - For #10, do we see any reason for having a unified photo or music
> manager, a la iPhoto or iTunes? Or, can we somehow transform a Project
> into that, so that the Project will contain all the albums/playlists,
> and we can tell the Project to just show all pictures or play all  
> songs?

My understanding was that playlists or photo albums would be projects  
themselves. When the project is opened appropriate widgets are  
displayed. In the case of a playlist the standard audio controls would  
be shown. I'm not sure how the playlist itself would be shown. I think  
in the end something very similar to today's audio management  
applications would have to be created (albeit in a more modular  
fashion).

Listening to music is usually a passive activity. The playlist is  
formed and playback is started. At this point the list, and even the  
audio controls, are not required. However, the audio controls need to  
be within reach as that is what the user usually interacts with.


_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss

[brian muhumuza]

On Sun, May 24, 2009 at 7:38 PM, Sebastian Nowicki <sebnow@...> wrote:

>
> On May 6, 2009, at 5:20 PM, Jesse Ross wrote:
>
>>  - For #10, do we see any reason for having a unified photo or music
>> manager, a la iPhoto or iTunes? Or, can we somehow transform a Project
>> into that, so that the Project will contain all the albums/playlists,
>> and we can tell the Project to just show all pictures or play all
>> songs?
>
> My understanding was that playlists or photo albums would be projects
> themselves. When the project is opened appropriate widgets are
> displayed. In the case of a playlist the standard audio controls would
> be shown. I'm not sure how the playlist itself would be shown. I think
> in the end something very similar to today's audio management
> applications would have to be created (albeit in a more modular
> fashion).
>

I think this would make things very complicated and confusing. It
would be better to have viewers that know how to handle a collection
such that it is opened like any other file. the viewer would determine
how to represent the list of objects. i don't think such a trivial
task should be done as a project.

> Listening to music is usually a passive activity. The playlist is
> formed and playback is started. At this point the list, and even the
> audio controls, are not required. However, the audio controls need to
> be within reach as that is what the user usually interacts with.
>
>
> _______________________________________________
> Etoile-discuss mailing list
> Etoile-discuss@...
> https://mail.gna.org/listinfo/etoile-discuss
>

--
//MB

_______________________________________________
Etoile-discuss mailing list
Etoile-discuss@...
https://mail.gna.org/listinfo/etoile-discuss