Directions for GNOME 3.0

October 29, 2008

This article was contributed by Jonathan Roberts

Earlier this year at the Gnome Users and Developers Conference, it was announced that there would be a Gnome 3.0 and discussions about how to make the transition are now open. Since then, there has been another gathering of Gnome developers, discussing and making plans about how they would like to modernize the interface. Over the past few days, a number of blog posts have appeared on Planet Gnome discussing some of the happenings at this five day event, and I felt a summary of the ideas so far might be useful to everyone concerned.

The Journal

The idea that has perhaps received the clearest exposition, along with some concrete work on beginning to make it a reality, is a refreshed way to handle day to day file management based on the OLPC's journal concept. Federico Mena-Quintero posted to his blog reporting his teams brainstorming session. What's wrong with how we handle file management today? Federico says:

Let's consider a very common workflow: download an image from a web site, make some modifications to it, and attach it to an e-mail. When you do "save image as" in your web browser, it will default to ~/Downloads or even ~/Desktop. When you do "file/open" in the GIMP, it will default to the last directory you used in the GIMP, even if it was from days ago (on my machine right now, the GIMP defaulted to look at files from ~/src/some-random-directory) ... The end result is that your workflow gets shattered to pieces, as programs try to be helpful within themselves, but they totally fail at being helpful within your workflow.

So, programs contribute to having files scattered around everywhere, and there is no easy way to look at everything together.

To solve this problem, they began from the premise that humans are fairly good at knowing when they did things: "I started typing my homework last Monday, because I knew it was due on my Thursday class" and "I mailed you that photo two weeks ago, right after my birthday party" were the examples given. From here, the argument is that if we can present users with a journal view of what they did, they can forget about where they put a file and just browse through a time line to find what they were looking for.

The journal would not only keep track of files you created, but websites you visited, IM conversations you had, and even allow you to make notes about particular entries. An example of this final kind of functionality might be noting down reference numbers from receipts or customer service representatives.The other two major features of the journal would be the ability to star important items, so they're kept in a separate section, along with the ability to create files from directly within the journal, allowing it to act as a kind of scrap book.

As well as Federico's own proof of concept implementation, you can also find similar ideas in Mayanna's timeline, a fork of Gimmie, and the Nemo file manager.

Task Orientation

This post didn't arise out of the User Experience Hackfest, but from GUADEC earlier in the year. Karl Lattimer has posited that the application centric workflow is broken, and that people don't use a computer with the intention of using a particular application, but with the intention of completing a particular task. Obviously tasks rarely stand on their own, but often form part of a larger project.

Karl comments that he believes Federico is making moves in the right direction with the journal, providing users with the capacity to track what they did and when - perhaps a kind of project management framework - but he believes that we also need to provide users with the ability to track why things were done, gathering metadata about the tasks and building a picture of the relationships between them. The example he uses is that of an email received from a colleague asking us to update a file by a certain deadline: from this we could extract the file, the deadline, who sent it to us, and possibly even what needs doing to the file, all of which could be fed into the journal or other interface. This obviously has some practical challenges when it comes to considering how it could be implemented, but if realized could deliver an automated task list that's closely linked with templates for commonly performed tasks, doing away with the idea of static workspaces and applications for ever.

Karl sums up his thoughts nicely in this paragraph:

For us to get there we need to invent some cool stuff, semantics is one part, organising the data by what it is rather than where it is, especially when the user has a tendency to loose things in the jungle of file systems. Journals and revision control are another part of it, remembering what we've been doing and when, but also templates and schema's are part of it too, hiding the notion of an application behind the tasks you want to achieve and the things you want to get done.

The Desktop Shell

During this hackfest session, the team tried to forget about the current Gnome interface and focus on what makes sense for users; ironically, Vincent Untz decided to start his post, about how the team forgot about the current Gnome interface, with some observations of the current Gnome interface. The problems he identified in the current interface were four-fold. Firstly, finding the window you want can be difficult when using the default applet, particularly if you have more than a few windows open, and particularly if you have a smaller screen. Secondly, few people make use of the multiple workspaces idea, largely because they were just unaware of their existence. Thirdly, application menus are a slow and inefficient way to open up new applications; some take advantage of launchers or the run dialog to improve on this, but most don't know how to do this. And finally, the current panel is certainly very powerful, but its power is wasted in unneeded flexibility such as being able to position the panel in the middle of the screen.

Perhaps the most controversial proposal to fix these problems so far is to restrict Gnome to a single static panel: by removing one panel we'd be saving valuable screen real estate, and by having a layout we can depend on we'd be able to use "hot corners" more effectively, allowing users to easily set their presence, as well as to launch a new "activities overlay mode". While the idea of a single panel hasn't raised too much concern, the static point has: Mathias Hasselmann responds with "Static Panel Nonsense", suggesting that many Gnome users, himself included, as well as Mac OS and Windows users, heavily customize the layout of their panels with custom launchers, and to improve something by removing existing functionality is not a good approach.

The most promising proposal from my point of view, and what seems to be a common OLPC inspired train of thought amongst Gnome's community, is the notion of activities. An activity is essentially what Karl Lattimer described as a project, made up of individual tasks, and what many Gnome users organize into separate work spaces in the current environment. In the current Gnome environment, Vincent argues, activities and work spaces are static: a user configures 8 desktops and sticks with them. His proposal is that activities should be far more flexible, and if a user wants to start a new one then we should help them by creating a new desktop automatically.

Where Next

Reportedly the release team are busy preparing a plan for how we can move from Gnome 2.x to 3.0, with the current plan appearing to be that what would have been called 2.30 will become 3.0. In this time frame, the very least of what we can expect to see is a revamped Gtk+, but what changes the user can expect to see is far harder to tell as there are no known plans for a radical interface overhaul like that seen during the development of KDE 4. Instead, it appears that the Gnome release team are planning on sticking to their current principles with regard to what features will become a core part of the desktop stack: adoption by popular distributions, stability, and a proven track record will all be required for features to make it in. This may seem like it rules out huge amounts of innovation, but there are a number of existing frameworks in Gnome that are very exciting (PolicyKit, PackageKit, Clutter, GVFS, desktop search, D-Conf, online desktop), and perhaps the 3.0 development cycle will see these mature and finally deliver on their promise of revolutionizing the user experience, with many of these technologies forming the backbone of the ideas discussed in this article.

Index entries for this article
GuestArticles	Roberts, Jonathan

to post comments

Directions for GNOME 3.0

Posted Oct 30, 2008 1:37 UTC (Thu) by paulmfoster (guest, #17313) [Link] (4 responses)

Regarding the journal view of files, I hope no one ever forces me into this. Would you file things in an office strictly by time? Users who can't remember where they put things are simply lacking the discipline of using a filesystem. You always put things where they go, and if there isn't a place for that type of thing, you make one logically. I would agree that programs should agree with each other on where to put files. In fact, one thing sorely missing in almost all configuration dialogs is "Where do you want me to look for your files?" and "Where shall I put files you create?" Seems simple but almost no program has a setting for this.

There's a similar silly argument about task-oriented workflow. It appears users simply want the computer to be a "wizard" and follow them around, anticipating their needs and not forcing them to actually consider how to do what they want to do. Instead, the computer and its programs are one and all *tools*. You don't hammer nails with a screwdriver. You don't build a house by pushing a button and having all the tools magically read the plans and build it. You use the exact tool for the exact job (and you put that tool back in an exact place where you can find it again).

Rather than attempt to coddle users who aren't really knowledgeable enough to be using a computer, perhaps our time would be better spent coming up with ways to educate users in how computers work and how to actually work properly with the tools.

I know. That'll never fly. We'll continue to get legions of people who can't find the power button but expect the computer to keep their finances straight. And software architects who cater to them. Led by Microsoft and Apple. I'll stick to mc for my file management, mutt for my mail and vi for my coding, thanks.

Journals

Posted Oct 30, 2008 7:38 UTC (Thu) by eru (subscriber, #2753) [Link]

Regarding the journal view of files, I hope no one ever forces me into this.

Yes, it should just be an alternative, but I can see why it would be very useful. I find myself using my email box like this.

Would you file things in an office strictly by time? Users who can't remember where they put things are simply lacking the discipline of using a filesystem.

By-time is a very useful default ordering, when you don't have the time or inclination to explicitly classify (again as a personal example, in a large directory I find my myself hitting "ls -ltr" frequently). It is also the case that most things (of course not all) become less relevant over time. So looking back in the journal you can more easily see items you want to classify somewhere else, and others that you can just as well delete.

So yes, I think the idea is great.

Directions for GNOME 3.0

Posted Oct 30, 2008 8:52 UTC (Thu) by NAR (subscriber, #1313) [Link] (2 responses)

Users who can't remember where they put things are simply lacking the discipline of using a filesystem.

I'm afraid that covers about 99% of casual users. Most of them can't use the "find" function as well. I think most of the improvements mentioned in the article are not useful for the poweruser (e.g. it's slow to startup an application from an application menu - I have a shortcut for often-used applications and use a shell to start not so often used applications), but could be useful for that other 99%. Of course, it all depends on how good the implementation will be, but it should be configurable, in order to not get into the way of powerusers.

Directions for GNOME 3.0

Posted Oct 30, 2008 15:05 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

It should end up benefiting the power users..

I know I lose were I place files all the time.

I use 'find' a lot to look for files I've made. The most often used command on my system is going to be 'ls'. I don't think that I am unusual for this.

So that's a big reduction in usability for me. I frequently drop to shell for all sorts of trivial things like that. Slows me down somewhat.

Having the ability to see files grouped by dates would actually be very useful since at work I typically see my time fractured. Over a week's time I may be working on 4 or 5 different things, some tasks taking short amount of time, other tasks taking several months. Often they are not directly related. I try to organize stuff by folders and whatnot, but I forget the names of folders and end up with a lot of clutter in my home directory.

I maybe working on something for few days time and end up getting side tracked for quite a while with a different emergency or new, more important task. Often I will simply lose my place and forget exactly were I left off. Being able to go back and see what files and programs I was using a while ago would help a lot.

Maybe programmers are used to having very focused, long-term tasks, were you are using the same stuff day in and day out, but that's not true for lots of people.

Directions for GNOME 3.0

Posted Nov 4, 2008 9:20 UTC (Tue) by stevem (subscriber, #1512) [Link]

The only time I tend to lose files is when GUI programs bend over backwards to hide where they've saved them to. Firefox is a real pain for this type of behaviour - I tell it to save a download and then I have to go looking for it. Openoffice always drops me back into my home directory when I ask it to save a new file, even if I've started it in the right directory. Painful.

Directions for GNOME 3.0

Posted Oct 30, 2008 2:50 UTC (Thu) by bojan (subscriber, #14302) [Link] (3 responses)

> restrict Gnome to a single static panel

Yes, please, but only as long as the word _static_ is taken out of that sentence. Current default with two panels just wastes user's time on moving the mouse up/down the whole screen all the time. However, users should be able to put their own stuff into the panel (i.e. the panels should not be static).

If more real estate is needed for stuff on the panel, we should have a corner panel (i.e. something that covers, for instance, top and left side of the screen, so that things are kept close to each other, not far apart like now).

> doing away with the idea of static workspaces

As long as the point here is the word _static_ (i.e. preconfigured number of workspaces). It is absolutely essential to avoid the classical Windows/Mac look where gazillion windows overlap each other and create unmanageable mess.

And it is not true that regular users don't know about workspaces. I support some that are so used to workspaces, that not having would greatly confuse them.

Directions for GNOME 3.0

Posted Oct 30, 2008 15:15 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

> If more real estate is needed for stuff on the panel, we should have a corner panel (i.e. something that covers, for instance, top and left side of the screen, so that things are kept close to each other, not far apart like now).

Heh.

Maybe the Gnome folks will fix the panel so it works vertically.

Typically now I simply eliminate the bottom panel. It's the first thing I do when running Gnome. I much prefer to have the bar at the top.

However when I worked call center it was invaluable to have the 'big fat panel' on the right side of the screen. Which XP was able to handle quite well. When coming to work I would always open up applications in the same order. This way when I was talking on the phone and needed to find information or a window immediately without interrupting the flow of the conversation I could find what I needed without any hesitation or thought. Time was very critical and stopping to go 'ummm' and 'ehhhh' as I clicked around windows looking for stuff just pissed off the already irate user and made my job harder.

Alt-tab is too slow and the fact that windows would be arranged based on the last ones I used was not particularly useful. A horizontal taskbar simply did not take up enough screen area to present a large target and a efficient way to list the large number of windows I needed to use.

With the way the LCD screens are made nowadays, being widescreen, means that having a horizontal bar presents a better use of space for many people.

Directions for GNOME 3.0

Posted Oct 30, 2008 15:47 UTC (Thu) by drag (guest, #31333) [Link]

Oh.

> With the way the LCD screens are made nowadays, being widescreen, means that having a horizontal bar presents a better use of space for many people.

Oops. Ment to say 'vertical' there.

-------------------------------

And besides the brokenness with vertical placement there is another set of irritating bugs that they need to fix...

Namely Gnome's multidisplay support blows.

Now that I have a laptop with a working Intel driver and the ability to hotplug displays I run in all sorts of nagging issues with my laptop and Gnome. My laptop will run for days, but I will frequently use multiple displays on and off:

* When you arrange icons in Nautilus with displays on top of one another Nautilus will happily use the entire available desktop area irregardless of which monitor the icons will land on. This leads to irritations like Icons cut in half at the edge of the screen and unreachable files after you disconnect a monitor and resize the desktop. So after disconnecting displays I am forced to re-arrange the icons. This totally defeats any sort of spatial referencing of files.

What should happen is that Nautilus needs to take into consideration the desktop and make sure that, at least, you don't have unreachable files.

* When running multiple monitors a bottom Gnome panel the bottom panel gets ignored. So when you have maximized applications the bottom edge of the window is shoved under the panel. This isn't a problem for most apps, since the bottom of the window is usually wasted, but for browsing I like to double check the URL of links before I click on them.

* Adding monitors, and arranging them in a 'stacked' manner can cause the panel to then be at the bottom of the top display and if you try to have a window that spans both displays (like Blender, for example) you end up with a Gnome panel floating around the middle of it. Something a bit more deterministic needs to happen with this.. instead of having the bottom panel be on the bottom of the first display, it probably should just be at the bottom of the desktop.

* When adding and deleting monitors the amount of horizontal display resolution will change. This causes the icons on the Gnome panel to re-arrange themselves. Same thing with dragging the panel around sometimes, I think.

The _order_ of the icons/applets is much more important then the spatial placement.

So one huge improvement that the Gnome panel can have is have 'gravity' to the left and right of the panel (or up and down in a horizontal arrangement). That is, when a person places a applet or application launcher on the panel it should automatically 'fall' to the left or the right and smoosh up against other icons. Then the order of the icons/applets need to be kept, and not how far left and right they are on the panel.

Then for people that want to have icons a bit isolated on the panel to make it easier to avoid clicking something next to it. You can add a invisible 'padding applet' that simply takes up a configurable amount of space and doesn't react to left clicking.

Right now I am just very irritated that every time I change my display the order and placement of the icons get scrambled.

Directions for GNOME 3.0

Posted Nov 6, 2008 10:54 UTC (Thu) by Penn (guest, #1890) [Link]

I wrote about my configuration that uses static workplaces that I use for ten years already over here:

http://skliarie.blogspot.com/2008/11/my-45-workplaces.html

It is not for new users, but IMHO, gnome should be extensible enough to support that sort of workflow.

Journal shmournal

Posted Oct 30, 2008 2:55 UTC (Thu) by tetromino (guest, #33846) [Link] (8 responses)

My biggest complaint about a journal-based interface is that it's impossible to remember when exactly you created a document if you created it a year ago. In other words, a journal is an excellent way to manage recent files (touched < 1 month ago), but completely unusable for anything you have on your hard drive that you haven't interacted with for a while. "There is this great photo I downloaded - probably the summer before last - or wait, maybe the summer before that - well, let's search the journal for all image documents, let's enter a 15-month range just to be on the safe side - oh wow, 4670 files, I wonder which of them is the one that I need?"

Fundamentally, there is no alternative to manually organizing information - tagging, well-designed folder hierarchies, informative file names. Until we invent strong AI, this will remain a task that the users simply have to learn to do on their own.

Journal shmournal

Posted Oct 30, 2008 7:01 UTC (Thu) by ebirdie (guest, #512) [Link] (5 responses)

Your comment got got me excited about an idea to apply tags and web browser alike address fields/bars in file dialogs/browsers. A file "address" field in the dialog/browser could complete and suggest both file paths and file names as you type. Shell alike completion with alt-tab (as tab is reserved in many file dialogs) would be a nice bonus. There could be a library of tags for naming directories and files. Tags could be inserted into the new names. Paths and files could be thus found with couple tags. Nice bonus in the file dialog/browser would be that the listing below the path/file address field is dynamically updated thus giving visually feedback where you are going to put your file, by what name and how other files therein have already been named and classified.

I just wonder, if the above haven't been yet applied to file dialogs/browsers somewhere. I think there isn't any new idea per se in the above description, just that is applied to file dialogs and file browsers.

Well, I hope I didn't resemble Windows file dialog in the above. Anyway the point is to apply those great input and categorizing methods already successfully implemented in shells and web browser address bars.

Tagging filesystems

Posted Oct 30, 2008 9:34 UTC (Thu) by lab (guest, #51153) [Link] (2 responses)

Yes, I've been exited about the idea of 'tagging filesystems' for a long time. The more I think about it, the more tags seems to me to be the best answer for the question of how to categorize the oodles of information we create for ourselves; much stronger than hierachial ordering. I would love for tags to be a natural property of a filesystem, and where that would automagically work with all FS tools, both high- and lowlevel. And yes, easy access to tag, and find by tags, in file-dialogs etc.

Maybe someone has already made this, and I'd love to get some pointers.

Tagging filesystems

Posted Oct 30, 2008 11:07 UTC (Thu) by appie (guest, #34002) [Link] (1 responses)

I wish there where 48 hours in a day (and me being able to actually use the extra 24 hours :), I could use them to hack up a proof of concept: tag oriented file storage is something I've been telling people about for a couple of years. I'm absolutely sure it would be very useful, for power users and everyone else alike.

The whole directory/file mantra is an outdated concept, it works yes, but tags can offer much more flexibility. And after all, using tags isn't that much different from creating a directory tree, in a sense one is already supplying meta data for the files stored in it: work related -> tenders -> customerName for instance.

One has to get used to the idea of describing the data we're working on and retrieving them by describing them ('tenders oct 2008' or 'tenders customerName'.)
Some tags can be auto generated like the date/time created, last consulted, filetype (text document, picture, ...). When for instance camera's get equipped with GPS by default, an automatic tag with the location can be added to every picture we store in the fs.

And it wouldn't be static, if I can only think of a limited set of tags at first and sometime later can think of more and better tags, I can always add them at that time.
Plus, my view on the data probably doesn't reflect someone else's view on it. Tags allow us to have one user describe data with one set of tags and another user describe it with another set of tags. Finally, at least digitally, no arguments on the illogical place where stuff was put by someone else, e.g. your SO :)

From using tags one can go to creating relations between objects stored and their tags.

Most modern file systems already incorporate meta data functionality. What's needed is a way to efficiently index and search the tags.
Plus of course the user interfaces to them.

Tagging filesystems

Posted Oct 31, 2008 15:02 UTC (Fri) by mjthayer (guest, #39183) [Link]

If the journal is not the main way to access the file system, but just an additional database of file paths in a file on the filesystem somewhere then the tags could be saved into the journal. Preferably the application creating/saving a file could automatically add a certain number (not least creator application).

Journal shmournal

Posted Oct 30, 2008 12:05 UTC (Thu) by tnoo (subscriber, #20427) [Link]

... you mean something like ido-mode in Emacs? That would be great.

Journal shmournal

Posted Nov 1, 2008 12:30 UTC (Sat) by bfields (subscriber, #19510) [Link]

Dig around a bit and I think you'll find a ton of projects, academic papers, etc., on tagging and metadata.

One problem, I believe, is: most of us have enough trouble just developing a consistent system for directory and file names. So we certainly aren't going to do a good job of assigning and managing a bunch of additional metadata. Except where it's standardized and automatically collected (digital photo timestamps, album info on mp3's...), it's probably a loss.

Nemo - 'cross between a calendar and a file browser'

Posted Oct 30, 2008 15:22 UTC (Thu) by southey (guest, #9466) [Link]

Perhaps you want something like Nemo http://www.iola.dk/nemo/?

Journal shmournal

Posted Dec 21, 2008 10:08 UTC (Sun) by anomalizer (guest, #53112) [Link]

nepomuk in KDE 4 is supposed to solve this kind of a problem. I've been trying kde 4 since the past 2 days, so I can't say for sure how it works but in principle, nepomuk is supposed to solve this exact problem

What about a "present working directory" for Nautlius then?

Posted Oct 30, 2008 9:20 UTC (Thu) by grantingram (guest, #18390) [Link] (7 responses)

When you do "save image as" in your web browser, it will default to ~/Downloads or even ~/Desktop. When you do "file/open" in the GIMP, it will default to the last directory you used...

This is something that winds me up on regular basis! But would you get to 90% of a solution by having open and save dialogs communicate with the file manger? That way if you had saved an image to ~/work/somerandomname a moment ago the GIMP would by default look for files in ~/work/somerandomname? rather than where you last worked with the GIMP?

Having said that the Journal idea sounds very cool and extremely worthwhile...

What about a "present working directory" for Nautlius then?

Posted Oct 30, 2008 9:46 UTC (Thu) by niner (guest, #26151) [Link] (2 responses)

Take an image from a webpage, manipulate it and mail it to a friend? Why not simply
right click on that image, use "Open with" -> "Gimp", manipulate it, copy and paste it to
that email. There is no need to save any version of that image in any directory in that
example. Works perfectly well in KDE and I assume that gnome has similar capabilities.

There are for sure use cases that can profit from improvement. But this example seems
to be pretty badly chosen.

What about a "present working directory" for Nautlius then?

Posted Oct 30, 2008 11:31 UTC (Thu) by kragil (guest, #34373) [Link] (1 responses)

Works in KDE != Works in Gnome

What about a "present working directory" for Nautlius then?

Posted Oct 30, 2008 11:39 UTC (Thu) by niner (guest, #26151) [Link]

If all that's missing is this "open with" entry in the menu, maybe it's better to just add
that and get all the benefits with just a minor change.
OTOH IMHO Gnome's file dialog can only become better anyway, so no harm done.

What about a "present working directory" for Nautlius then?

Posted Oct 30, 2008 11:40 UTC (Thu) by epa (subscriber, #39769) [Link]

But would you get to 90% of a solution by having open and save dialogs communicate with the file manger? That way if you had saved an image to ~/work/somerandomname a moment ago the GIMP would by default look for files in ~/work/somerandomname? rather than where you last worked with the GIMP?

A very good idea.

But take a step back and consider why does the GIMP or any other application need a 'File Open' dialogue box at all? Why does it need its own crippled little file manager duplicating the desktop's file manager? To open a file, it would be simpler to just open the directory using the ordinary file manager and then double-click the file or drag it onto the GIMP's icon in the panel.

In single-tasking environments of course an application needs its own filepicker. But why bother with it now? A list of recently opened files (or the directories containing them) would be a convenience. Otherwise, let each program do one thing well - use the file manager to navigate through files.

What about a "present working directory" for Nautlius then?

Posted Oct 30, 2008 12:29 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (2 responses)

As for this particular use case, I just did:
1) rightclick on picture in Epiphany, select Save picture, save it somewhere
2) open GIMP
3) Choose File->Open
4) In file selector, just under Search there is "Recently used", click it
5) from few files shown, first is picture I just saved.

And this is on Fedora 8, not even the latest software. We already have solution for this problem, maybe it's not marketed enough?

What about a "present working directory" for Nautlius then?

Posted Oct 30, 2008 16:29 UTC (Thu) by kragil (guest, #34373) [Link] (1 responses)

In Debian Sid Gnome(without evolution):

Right Click Image in Iceweasel
> select copy mage
Open Gimp
>file > paste as new image
Edit
>file > Send as email

THAT would not be bad actually.

But the Gimp send as email dialog is _VERY_ rudimentary (in other words: worthless).

So
> Save
Open email client
> New email
Attach > find file in file dialog.

That workflow is pretty bad if you ask me.

What about a "present working directory" for Nautlius then?

Posted Nov 4, 2008 15:15 UTC (Tue) by dgm (subscriber, #49227) [Link]

In my mind, the right workflow would be:

Open the mail application
Create a new message
Open the browser (Iceweasel or whatever)
position the mouse over the picture and drag it over the message window

Now, the right workflow for opening it with the GIMP:

Open the GIMP
drag the image over it

right click the image, then select "open with" and then "Image editor (the GIMP)".

You don't need to save the image to disk at all.

Directions for GNOME 3.0

Posted Oct 30, 2008 9:45 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

the journal is one of the worst features of the OLPC software.

there is a lot of debate over how to improve it to make it useable, or if they should just switch to a normal filesystem.

just about any programming project (including html) is just about impossible with the journal approach instead of a filesystem.

another major problem is that with auto-save the journal fills up with lots of junk that you have to wade through to try and find the stuff you care about.

if gnome tries to push everyone to use a journal it will be a really big reason to use something else, _anything_ else

Directions for GNOME 3.0

Posted Oct 31, 2008 15:08 UTC (Fri) by mjthayer (guest, #39183) [Link]

If the journal is not the primary means of accessing the filesystem, but just an additional database of filepaths, saved in a file on the filesystem and explicitly updated/written to by the applications creating the files then things get much better. Particularly if the file references in the journal can be tagged (automatically by the creator application or manually by the user). At a minimum, a tag naming the creator application simplifies searching greatly.

An alternative suggestion...

Posted Oct 30, 2008 9:48 UTC (Thu) by dan_a (guest, #5325) [Link] (11 responses)

Perhaps the solution to the workflow problem would not be the journal file view, but programs more oriented to workflow.

Instead of doing "Save Image As" and then opening GIMP, what the user really wants to do is "save the image on my computer and open it with GIMP." Might it not be better to have this as an option in the web browser? And then of course GIMP could have "save the image on my computer and email it to..."

I do like the idea of increased task orientation, though.

An alternative suggestion...

Posted Oct 30, 2008 11:45 UTC (Thu) by epa (subscriber, #39769) [Link] (10 responses)

When you 'save image as', instead of disappearing to some random location it should open the directory where it's being saved in the file manager. Then you can see your file appear, and double-click or right-click to open it in the app you want.

Better still would be for the user to choose a directory with the file manager, then *drag* the saved file from the web browser to that directory. This gives the user a physical sense of where the file is going and makes sure you can never lose track of where something was saved to. But I don't have much hope that mainstream desktop environments will adopt this, because it's too different to what Windows does, and this style of UI normally requires you to have overlapping windows on the screen, which is very awkward with window managers like Metacity that force a window to the front on any mouse click.

An alternative suggestion...

Posted Oct 30, 2008 13:52 UTC (Thu) by kh (guest, #19413) [Link]

> When you 'save image as', instead of disappearing to some random location

I can not help but think that at least part of the problem is that gnome (and every other gui) does not have a persistent current directory, unlike any tui (e.g. bash). When I am working in a shell, much of the commands I can give the computer are dependent upon my current working directory, but somehow that never was translated to any of the gui environments. Maybe each workspace needs a current working directory that can be changed from the panel or any of the programs in that workspace, and that is enforced for all programs in that workspace.

An alternative suggestion...

Posted Oct 30, 2008 14:54 UTC (Thu) by niner (guest, #26151) [Link] (4 responses)

"Better still would be for the user to choose a directory with the file manager, then *drag*
the saved file from the web browser to that directory. [...] But I don't have much hope
that mainstream desktop environments will adopt this"

Just tried that on my KDE desktop and it worked exactly like you described. I'd not be
surprised if the same were already possible on Gnome, too.

An alternative suggestion...

Posted Oct 30, 2008 18:13 UTC (Thu) by epa (subscriber, #39769) [Link]

I mean that dragging the file to a directory window would be the default and most common way of saving, used most of the time by most users. At the moment you can do it, but far more common is for the app to silently dump the file in some random place (web browsers) or use its own crappy filepicker to navigate to the location you want.

An alternative suggestion...

Posted Oct 30, 2008 20:06 UTC (Thu) by massimiliano (subscriber, #3048) [Link] (2 responses)

Just tried that on my KDE desktop and it worked exactly like you described. I'd not be surprised if the same were already possible on Gnome, too.

IIRC in Gnome it has worked that way with Epiphany for ages.
With Firefox, on the other hand, it creates a link on the destination folder, which IMHO is not as useful as downloading the file or image.

An alternative suggestion...

Posted Oct 30, 2008 21:57 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

Epiphany works a lot better for a lot of things in Gnome. Stuff like that. And besides that it's a bit faster to start up and uses less RAM then firefox.

And for older systems you have the option to use Webkit.

Oh, and it doesn't abuse "Fsync" like Firefox does.

OF course, Firefox has lots more capabilities. But all I want is a browser.

An alternative suggestion...

Posted Nov 4, 2008 3:20 UTC (Tue) by Ze (guest, #54182) [Link]

Just out of interest how does firefox abuse fsync?

An alternative suggestion...

Posted Nov 6, 2008 10:00 UTC (Thu) by MortFurd (guest, #9389) [Link] (3 responses)

Better still would be for the user to choose a directory with the file manager, then *drag* the saved file from the web browser to that directory.

Dragging is the WORST concept ever. I work at a help desk. Do you know how often users lose files by dropping them somewhere accidentally? Do you know how much a of a pain it is to try to locate a dropped file? Worst part of it is that the users don't generally notice that they dropped it in the wrong place until MUCH later - then you get vague requests for help "Well, I was using it last week or maybe the week before. And I think it was called Budget2009 or may be ProposalforNextFY. Or something else. I don't know. Can you help me find it?"

Whoever thought drag and drop into the file system was a good idea had absolutely zip to do with real world users.

An alternative suggestion...

Posted Nov 6, 2008 13:42 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

Dragging is the WORST concept ever. I work at a help desk. Do you know how often users lose files by dropping them somewhere accidentally?

Hmm, I imagined (based partly on my own experience) that dragging to save a file would reduce the occurrence of lost files. First you must explicitly navigate to where you want to save the file - no more mysterious default locations; if you don't know how to locate a directory then you cannot save a file there. Secondly, once you've dragged the file into the window then it is still open and you can see your file there.

Of these help desk requests, how do you know that they are caused by drag-and-drop saving rather than other causes, such as the unintuitive behaviour of filepickers? In my experience helping technically naive users, the filepicker interface with its arbitrary choice of directories and unclear navigation is responsible for many more lost files than explicit dragging between one directory window and another. 'Uh, I don't know what directory - I just pressed Save... and now I come back to the same program and I don't see it in the list.'

(Part of the problem is that by default in Windows Explorer dragging a file within the same drive moves it rather than copying it. IMHO copying, being the safer operation, should be the default.)

An alternative suggestion...

Posted Nov 6, 2008 15:38 UTC (Thu) by MortFurd (guest, #9389) [Link] (1 responses)

'Cause users (who have just loast files) tell me they were dragging files from one place to another when they lost them.

I've also dropped files myself. A twitch of the finger at the wrong moment, and the file (or, god help you, the pile of 3 gazillion files that you selected) gets dropped in the wrong folder. I try to avoid drag and drop - I tend to select items and ctrl X them then got to the new location and ctrl V them.

Did you ever have to try and locate a pile of lost email messages that a user lost? Same problem. Drag and drop within the mail program, and dropped into the wrong place - bzzzp! Gone! Now try to collect those messages from wherever they got to, and sort them out of whatever was in that folder to begin with.

Drag and drop as a file management tool is a Bad Idea (tm.)

An alternative suggestion...

Posted Nov 7, 2008 13:56 UTC (Fri) by epa (subscriber, #39769) [Link]

Did you ever have to try and locate a pile of lost email messages that a user lost? Same problem. Drag and drop within the mail program, and dropped into the wrong place - bzzzp! Gone!

I might have experienced something like that. But I think I blame the tree interface down the left hand side. There, it is much too easy to get the wrong thing. But if you have one window open for one directory and another window on a different part of the screen for another directory, and drag from one to the other, it seems fairly idiot-proof to me. Windows are big things and it's hard to get the wrong one. (And again, if you do not know how to navigate to a directory and display its contents in a window then you have no ability to put files there. This is not really true of the tree view.)

So I think I would say two things: dragging a file, by default, should *copy* it not move it so you can't lose stuff, and the fiddly tree view down the left of the window is handy for experts but too easy for novices to mess up, so it should be hidden or essentially read-only by default.

Ctrl-X Ctrl-V is essentially equivalent to drag and drop, IMHO, because the same principle applies: you see one place on the screen for the old location, a different place for the new one, and you can feel you are copying *from* here *to* there. I'd be happy enough if that were the default way to manage files and load and save them. What I don't like is the proliferation of fiddly, half-broken file managers instead of one good file manager across the whole desktop. I also don't really like the way directory structure gets hidden from the user, so you can save a file to a directory without any idea of how to get back there. Fix both of those and I'd be happy; it doesn't particularly have to involve holding down a mouse button while moving.

Directions for GNOME 3.0

Posted Oct 30, 2008 23:12 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

> To solve this problem, they began from the premise that humans are fairly
> good at knowing when they did things: "I started typing my homework last
> Monday, because I knew it was due on my Thursday class"

Uh. I'm usually like, "I think yesterday or the day before I went grocery shopping. Hell if I know, there's food in my fridge now."

Major things I've done in the past 2-3 days can be transposed out of order; after 5 or 6 days I can't tell you what day exactly I bought the video game I've been playing for 12 hours a day, or even when my hire date for my newest job was.

As long as they feature freeze GTK+2.0 and implement GTK+2.0 as a thunking library to GTK+3.0 for any API changes this time I'm fine.

Directions for GNOME 3.0

Posted Oct 31, 2008 9:08 UTC (Fri) by xav (guest, #18536) [Link]

s/GAUDEC/GUADEC/

(sorry to nitpick again)

journal, a.k.a. "context browser"

Posted Oct 31, 2008 23:14 UTC (Fri) by roelofs (guest, #2599) [Link] (2 responses)

The journal would not only keep track of files you created, but websites you visited, IM conversations you had, and even allow you to make notes about particular entries.

It's great to see this happening. Many years ago, in a past life in a consumer electronics research division, I had the same idea: something that would track calendar info, digital photos, filesystem changes, e-mail, television schedules, browser(s) history, etc.--ideally across multiple machines--and allow one to browse some or all of it in a unified fashion. I called it the "context browser," and my hope was that it would do more than simply help with "where did that file go?"--I wanted to answer questions like "where/when did I come across that information that I only vaguely recall?" Obviously filtering and other UI elements (non-linear timeline, freeform visualization, etc.) would have been critical to making it truly useful.

Unfortunately, it never went anywhere; the last economic downturn took its toll, and the project (and group :-) ) got whacked before it got fully underway. So it's good to know that other folks are working on similar ideas. Maybe one of these years I'll have a chance to get back to it...

Greg

journal, a.k.a. "context browser"

Posted Nov 27, 2008 6:23 UTC (Thu) by humsuploh (guest, #55344) [Link] (1 responses)

If not a workflow approach based solely on either the journal or tagging alone, why not one that combines both journal, tagging along with a revision control system? Like the task/functionality-based scheme to panel design as is embraced by Mayanna. Also while this has nothing to do with GNOME and more a kernel and specifically filesystem issue, isn't it high time that we have option of filesystem rollbacks like Solaris's ZFS offers? Think of the benefits people.

journal, a.k.a. "context browser"

Posted Dec 7, 2008 1:29 UTC (Sun) by seilo (guest, #55462) [Link]

Check out Gnome Zeitgeist
http://live.gnome.org/GnomeZeitGeist
It's still a prototype based on Mayanna/Gimmie try it out you might like it!