UX feedback after few days

[Tomasz Sterna]

Hello.

After using gnome-shell for a few days I think it's great!

And as there always is something to improve I would like to share some
observations.

1. Right click menus are hardly discoverable. I had no clue how to add
apps to favourites until I read cheat sheet. I even resorted to editing
GConf keys directly.
I would suggest small pin in the corner.
Or making the application name on the icon separate clickable area, that
shows the dropdown menu.

2. All applications menu is hard to use with apps that have longer
names. With apps like "Opera" it is no problem, but if I see
"Editor ..." I really have no idea what the app does.

3. Bottom notification area telepathy chat client is great. But I think
it should be provided by separate application utilising gnome-shell
provided infrastructure. It may be a killer feature, so it may be a
mandatory (but switchable) dependency.
And it does not play nice with Empathy. It eats messages before they
reach Empathy, so I have no chance of seeing them later in Empathy chat
history.



-- 
Tomasz Sterna
Instant Messaging & EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/  http://www.xiaoka.com/

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Suggestions.

[Cliff Resnick]

It's great to be able to launch an application by typing the name (and
keyboard integration is generally very good in gnome-shell) but good luck if
you don't know the name. Maybe indexing on categories would be useful for
type-searching. But for those who don't want to type, finding a program by
looking at a grid of little square pictures is pretty useless.

On Fri, Apr 2, 2010 at 10:02 PM, Mark Curtis  wrote:

>  I am not saying which is better, but other than "it's different" why is
> "an alphabetically sorted grid" worse?
>
> --
> Date: Fri, 2 Apr 2010 16:10:25 -0600
> Subject: Re: Suggestions.
> From: appi2...@gmail.com
> To: rovanion.luc...@gmail.com
> CC: gnome-shell-list@gnome.org
>
>
> Can someone explain to me why an alphabetically sorted grid is in any way a
> better way to browse applications? Change is only good when it improves, not
> makes worse.
>
> On Thu, Apr 1, 2010 at 12:47 PM, Rovanion Luckey <
> rovanion.luc...@gmail.com> wrote:
>
>
> Well maybe there should be something more like two ways of sorting and two
> ways of listing:
> Sorting; Groups and Flat
> Listing; Grid and List
>
> Three of these options have already been in the codebase at one point. The
> third, Groups with Grid view, could easily be implemented. The job is
> already done.
>
>
> --
> www.twitter.com/Rovanion
>
> ___
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
>
>
> --
> appi
>
> --
> Hotmail has tools for the New Busy. Search, chat and e-mail from your
> inbox. Learn 
> more.
>
> ___
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Finding and Reminding, tech issues, 3.0 and beyond

[Alan Cox]

Or just folders in the Calendar ? You don't write the contents of
everything on the calendar you put them in the filing cabinet or similar
with the same date attached.

> And certainly we do think of putting files onto the "Desktop" as posting
> them to attend to in the future. I don't think we'd want to always want
> to make users assign a date to that action, but you could imagine
> allowing that optionally, perhaps with the drag-to-calendar gesture.

Drag to calendar would probably to be coupled by re-appearing on the
desktop close to the date ?

> things. There are basically three reasons to delete things:
> 
>  * Organization - be able to find things.
> 
>  * Save disk space. Hard drive manufacturers are largely solving this
>for us. Certainly there are still movies/ISO images/kernel git trees/
>etc - things that take significant amounts of disk space. But most 
>files just aren't big enough to worry about.
> 
>  * Privacy. Some things you don't want hanging around. This use case
>is as much there as always. 

Four (maybe 5)

* Legal

* Backups

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Finding and Reminding, tech issues, 3.0 and beyond

[Jamie McCracken]

On Sat, 2010-04-10 at 17:10 -0400, Owen Taylor wrote:

> 
> The reason I consider storage relevant is that throwing data into "an
> optimized SQL database" where you don't have any ability to control what
> is indexed or understanding how query plans are executed is usually a
> recipe for application performance disaster. There are many people who
> make an excellent living going in and fixing these sorts of application
> performance disasters.
> 
> Now, to the extent that we're building GNOME and Tracker together as a
> system and we know what queries we need make fast - what standard
> properties need to be indexed - we're OK. For our "Finding and
> Reminding" plans I don't see a problem.
> 
> But if we go beyond that and start encouraging people to start putting
> all sorts of application data into Tracker and relying on Tracker to do
> efficient queries on it, then it definitely is a concern. Based on how
> Tracker is mapping RDF into SQL tables, some SPARQL queries are going to
> be fast, some are going to be dead slow and people need to be able to
> come to an understanding of which are which.

This is indeed true but one of the goals of our RDF implementation was
that there would not be a significant performance difference between
using a custom sqlite database and trackers DB.

If there are significant performance issues then we would need to be
notified of them and hopefully they can be resolved at the tracker end
(or even better at the ontology layer as we have custom properties to
indicate if a field should be indexed in sqlite)


> What do you see as the distinction between between "general event
> logging" and "timeline info"?
> 

Timeline to me means audit info like when a file was opened or a music
track played - this is the kind of stuff that tracker would want to
support natively 

Event logging could be anything and AFAIK zeitgeist plans to track
things like application focusing and probably stuff that the old Beagle
based Dashboard did. 

I really see zeitgeist as providing info like show me "all related
documents to this document" where it could draw upon contextual stuff
like Doc X was viewed whilst Doc Y was viewed and infer a relationship
between the two items. Tracker could only relate stuff where user
explicitly set such links (like via a common tag). This is the key
difference between zeitgeist and tracker as I understand it 


> This kind of "we can do some sorts of event logging, but other event
> logging is Zeitgeist" distinction is, generally speaking, Not Helpful. 
> Everybody needs to have a solid idea of what the components are and how
> they fit together.

Well the problem is that metadata in tracker is generally persistent and
has indefinite lifespan until changed by the user. Event logging is at
best semi-persistent in that as it ages its usefulness decreases and
should ultimately be discarded when its too old to be useful. I can see
audit data as having a long enough lifespan to add it to tracker
> 
> I certainly do have a concern that if some data is stored in an event
> log that Zeitgeist maintains and some data is stored in the tracker
> database that queries will be inefficient. If displaying a list of the
> last 100 files tagged as "download" by time requires getting a list of
> all files tagged as "download", querying Zeitgeist for all events on all
> those files, then sorting by time in the application, that potentially
> will suck.

I dont see a problem with storing such semi-persistent or temporary data
separately in zeitgeist provided your interest is centred around a
single URI. (IE queries like show me all related stuff to URI X). This
is perfectly manageable across tracker/zeitgeist. As you and I have both
said, its not manageable when you need it for large scale queries which
return multiple URIs but so far audit timestamps is the only case I know
of where thats common


> 
> If in the future Zeitgeist is using Tracker as a backend and is
> primarily about *writing* information into Tracker, and applications can
> query that information directly through the Tracker API, then that
> problem does largely go away. If Tracker is only used behind the scenes
> for storage in an opaque way, that wouldn't help because the app would
> still have to fetch two separate sorts of information and integrate
> them. Even if they were under the hood coming from the same place.

As above it really depends how you intend to query stuff (small scale vs
large scale). In the end its more about convincing the zeitgeist team to
make full use of trackers storage abilities (something which they are
reluctant to do atm)

jamie



___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Finding and Reminding, tech issues, 3.0 and beyond

[Jamie McCracken]

On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote:

> Tracker
> ===
> 
> In some testing, Tracker 0.8 seems enormously better behaved
> than Tracker 0.6. It has very significant optimizations in how
> it stores the tracker database on disk, and also, by default,
> only indexes defined subdirs of $HOME. So, as of right now,
> system-impact of Tracker isn't a big concern of mine, as it
> would be for 0.6.
> 
> Possible concerns and considerations with Tracker:
> 
>  * RDF + SPARQL + a large collection of ontologies does present
>a significant new barrier to someone coming to the GNOME
>platform. While the basic concepts of RDF are quite simple,
>RDF serialization formats and SPARQL are new learning people
>will have to do, and there are some intimidating terms
>like "ontology"

ontology = schema, so just semantics really :)

>
>RDF is also popularly (and perhaps unfairly) seen as
>yesterday's fad.

RDF is indeed not as nice or succinct as it could be but what would the
alternative be?

Also bear in mind that nepomuk ontology, which tracker uses, is shared
with Kde and hence it should result in some nice freedesktop coperation
and allow tracker to meet the needs of KDe apps as well as Gnome.

It would also be unwise to store shareable metadata without some
onto/schema which all apps can agree on

>
>  * There is a large abstraction barrier between the application
>and the underlying data storage. It's very hard to decipher
>or influence how storing data in RDF and running SPARQL queries
>maps into low-level database operations.

Not sure why that is relevant?

FYI, resources are stored as individual tables and all properties of a
resource are fields in those tables so the end result would not be much
different from a traditional sql database. 

Indeed its nothing like an off the shelf triple store which stores
individual properties as rows in a gigantic table which has poor
scalability (although great extensibility). Ergo tracker should be seen
as an optimised SQL database but which uses RDF/Sparql as its table
schema and query language  rather than SQL


[snip]
>
> Zeitgeist
> =
> 
> The "properties of files" approach of Tracker works for a lot
> of things. However, it is pretty much unsuitable for storing
> time-based histories of actions. We can store the last time
> a file was edited as a Tracker property. It's slightly harder
> to store all the times the file was edited. It's considerably
> harder to store all the times the file was edited including
> the editing application for each access.
> 
> (Of course, anything can be stored in RDF; it's a perfectly
> general format; however, the more that we have to create
> anonymous nodes, the more different structures that we are
> storing in the tracker triple store, the harder it is going
> to be to optimize, and the less suitable a straightforward
> implemention of the triple-store backed by a sqlite database
> is.)
> 
> My understanding is that the Tracker people have disclaimed
> the log storage problem. 

Not really. Storing timeline info is not a big deal for tracker. just
like a file can have many tags in tracker, it could also have many
histories or audit trails. It could also simply be just a multi-value
date property if all you stored was the datetime stamp

We would want a timeline ontology to be part of nepomuk if possible so
discussions with them would be needed first. Failing that, a tracker
specific timeline property could easily be added to all objects

tracker is definitely the right place to add timeline info if you intend
to do queries like "get me all music files I played last week" or "get
me all documents I viewed recently with author blah". I have heard of
one project which uses tracker to get data but then uses zeitgeist to
filter it for timeline info which is clearly not a good solution and
wont scale if the tracker results were huge

General Event logging could also be added to tracker but its usefulness
is not as great as say timelining and we dont really want to stamp on
the zeitgeist teams feet at this point. In the future, zeitgeist may
well decide to use tracker as an event logging framework but it is their
decision at end of the day

jamie



___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Finding and Reminding, tech issues, 3.0 and beyond

[Alan Cox]

>   The other approach is when expiring or archiving to move files
>   from ~/Desktop to an archival location like ~/Documents.

How does moving it work with non aware applications or a shared file
space ? You risk opening a file having it moved, saving it and ending up
with a copy in documents and one stale  which could lead to nasty user
errors. Seems safe to just filter the view (after all large directory
enumeration ought to be fast these days ?)

As a completely off the wall comment related to this - the fact I can't
drag documents into my calendar annoys me, because that's effectively how
some people organise some things in the paper world. I guess that backs
up your model but it does mean I expect to see my desktop bits from a
date in with my calendar.

Is stuff migrating to a filing cabinet by date ("This wek, last week,
march, ...) a metaphor for the desktop - > time stuff ?

Also I guess this lets you fix the bin so you can delete last weeks
documents rather than just "empty trash". It's mildly amusing that you
still seem to have to use "find" incantations to make the bin work well 8)

Alan
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Finding and Reminding, tech issues, 3.0 and beyond

[Johannes Schmid]

Hi Owen!


> What, if anything, gets pinned automatically is an interesting question
> - there's a pretty strong case if I create a new word processing
> document it should automatically get pinned. But if I save an email
> attachment, probably not? If everything is pinned, that's pretty much
> the same as pinning nothing. Pinning something to the desktop is making
> a "todo" item - it's something that you think you'll need to attend to
> in the future.

Saving an e-mail attachment is something I really would like to have
pinned because I always forget where I put it. Anyway, there may of
course be cases of things you don't like to pin but that is really
difficult to estimate before you have tried.

> I assume that by "the activity journal" you mean a UI like GNOME
> Activity Journal, and not the current GNOME Activity Journal? (It
> wouldn't really be possible, or at least at all easy, to to use a
> separate pygtk program within the GNOME Shell Overview.)

Yeah, of course I mean the UI of the activity journal (or similar, more
cleaned, whatever).

> My quick take on the issue is that its a question of density - the GNOME
> Shell overview is meant to make as much as possible immediately
> available to hand. Because repeats are shown, and because of the fixed
> time organization, the "activity journal" presentation is quite low
> density. This is even more the case when narrowing using cross-cutting
> filters... if I only want to see the slide presentations, then the vast
> majority of days in the last year will have no activity at all.
> 
> But certainly there are cases where using episodic memory, where drawing
> the connection from one document to a related document is of great use.
> I probably can find my slides from GCDS pretty easily with search (they
> are called 'gcds.odp'), but how do I go from there to the SVG source of
> the illustration 'shell-components.svg'?
> 
> If I could somehow pop from finding gcds.odp to a calendar/timeline view
> of all the times I edited that file, then it would be easy to find the
> SVG file. Ther are some interesting ideas there, and there are also
> considerable design challenges (a simple one is that there is no way to
> "select" items in the overview design - it's single click activation.
> And anything you put into a right click menu might as well not be there
> for most users.)
> 
> [ Obviously related: "Search by iterative date comparison" in
>   http://www.gnome.org/~seth/zuhanden-gnome3.pdf ]

I am really not a good UI designer but I would feel that a possibility
to switch between a time-based view and a flatter ("recently used" view
wouldn't clutter the UI much and wouldn't clutter too much. Basically
the two uses cases that you described above:

* I just worked on a document and need to change it now => recently used
view
* Someone calls telling talking to me about something I did last
week/yesterday/half a year ago and I need to find it => time-based view

There might be the need to filter things a bit more (search box, files
only, activities (e.g. website, chat, etc.) only.


> Would would a soft dependency on Tracker mean?

Not a discussion I want to take. Time for distributors to step in...

> What the central points of 3.0 are have to be based on how they fit into
> the overall vision. If an activity-journal like view makes sense in the
> overview, then we should implement that and market it for 3.0, but we
> shouldn't be forcing an activity-journal into the overview *just*
> because it's something that has been discussed in the planning for 3.0.

Sure, but IMHO it's useful in the overview (see below).

> So, if you want an activity-journal than there has to be design-side
> engagement to figure out how it fits in. If it replaces the current
> loosely chronological view in the mockups, how does it accomplish the
> same tasks? How does it relate to the "Desktop"?

As far as I remember the design, the desktop was seen as a place to
temporary store stuff. At least that is how it's used by some/most
people.

If we go with the pinning approach I would simply drop the desktop as
something physical and replace it by views that show what I would want
to see on the desktop. 

Compared with this mockup
http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding?action=AttachFile&do=get&target=desktop-view.png
we would have
* New (or Recent, I guess recent fits better) - flat view
* Frequent - flat view
* Calendar (sorry, I am sure there is a better description for it) -
something like activity-journal

Short note on whether to use zeitgeist and/or tracker: It doesn't matter
too much what we use. If tracker supports something like an
activity-journal later (which was indicated by the tracker developers) -
that's cool, we can use it then. But it currently doesn't and it doesn't
look like it would for 3.0. So I think it's reasonable to use zeitgeist
for it now, as it can do all of those things. If the backend is kept in
a way that it can be replaced we