Before I go to bed let me quickly present the first prototype of the semantic save dialog:
I tried to take into account the great ideas you all gave me, the mockups provided by some of you (very nice work). Of course my current QWidget-based design does not allow to easily create some of the fancier things that were suggested but that can be done later on once the functionality is all there.
There is still a lot of work to be done but the first version is working and I can go to bed now.
Trueg's Blog 
I’m not convinced that this is better than the current Save dialog, but anyway, here are some suggestions.
While this dialog looks pretty clean, I think it’s confusing (from a regular user’s perspective) with all these boxes. Therefore I propose a two-step process:
1. The dialog shows a text box (called main box from now on) for the file name, a way to select where to save the file, file type/encoding; only information needed to save the file.
2. When you click on Enter (or Save), these elements are replaced by widgets showing “Nepomuk-related” information, such as tags, comments etc., and you can click on the fields to add or change something.
The main box is more than for entering a filename, it’s a “smart box”. You can also use it for e.g. tagging with #tags, @ to add relevant contacts or places etc. (with autocomplete!). There can also be buttons/dropdown lists below the main box for adding these things as well as document type, comments, you name it. Finally, there should be a (?) button to the right of the main text box that shows the smart shortcuts.
For some inspiration, see Facebook (guess it’s not very popular around here…) and Remember The Milk.
Probably not everyone wants to see the second set of widgets for metadata, so there should be a “do not show this again”, and preferable a global option for using the normal Save dialog. If “do not show this again” is checked, there should be an easy way to show it again so the user can uncheck it.
Finally, in your screenshot, is that a breadcrumb navigator? It would be nice if you could expand it to navigate around, similar to the Mac OS X dialog. If you already can it’s not very obvious from the screenshot.
So I made a quick mockup: http://hanswchen.files.wordpress.com/2011/09/nepomuk_mockup.png
It’s less clean than your screenshot, but it resembles the old Save dialog more and I personally think it’s clearer what you’re supposed to do with it.
From top to bottom:
1. Place combobox and Browse button.
Lets you easily choose one of your Places in the combobox. Clicking on Browse will change the combobox to a breadcrumb bar, and possibly show back/forward/up buttons. The Browse button then becomes a Places button.
2. Context view
Showing context as hmmm below wrote about. This includes related files, related Nepomuk information etc.
Something to ponder: should this view show folders in the “Places” mode (see 1.), or only show folders in “Browse”?
3. Main box
The text box is the most important widget. It allows you to enter a filename, but also add tags and other Nepomuk-related information. If you exceed one line it’ll expand (much like the comment box on this blog).
Note the rich formatting (chosen rather arbitrary here) that separates the different text elements and “confirms” that you’ve typed correctly.
This text box also features auto-completion when you use #, @ etc.
Above the text box to the right is a button that, when clicked, shows a tooltip-like popup with information about different shortcuts (#, @ etc.).
Below the text box are some buttons that allow you to enter Nepomuk-related information (here I’ve just picked three icons). For example, the comment button may show a second text box under the buttons where you can enter comments.
The combo box to the right is for choosing the document type.
4. Save options, Save/Cancel
Finally there are some save options (depending on the application) and a Save and Cancel button.
This is just the first “step” (see parent post), I’m not too sure about the second “fill in metadata” step anymore. Ideally you should be able to enter all information here.
Thanks for all your hard work.
There is, I think another thing you might not have considered: physical folders (especially with previews) provide context. For example: if I am writing a paper and save a new figure, I like to see the previews of the other figures, that way I can ensure naming consistency, and can remind myself of what I might still miss.
This dialogue looks like it considers files/documents to exist in isolation — of course, you specify the project/tags etc., but you do not _see_ the other files. A fileview widget, perhaps with a mix of virtual and real folders would provide the context. Why not have what you have as an additional panel to the current save dialogue?
It is important (to me — but I guess I am not alone) that this dialogue can also be used as a classical dialogue: the GNOME save dialogue is horrible (it really is) because it makes it extremely inconvenient to navigate the file hierarchy. The KDE one is brilliant, because it makes it easy, and makes the network transparent. The goal of enriching the hierarchy with meta-information is great. if picking tags is harder than picking folders (as it must be: there is no single right answer with tags), and users are expected to pick tags first, you have a loser… semantic info means that you should be able to guess the folder based on the tags — and learn the tags from the choice of folder:)
You raise a very good point. I will try to integrate related files to provide some context.
As for the folder browsing: right again, that is where KDE is strong. My hope is that with an iterative approach I can reach a good combination of both in time.
Or, it could show previews of files with similar annotations. In your example, you would have your figures in a folder like
manuscript_for_nature/figures
But if you use Nepomuk, you would have properties “related to: manuscript” and “type: figure” so you have all the same information and probably more. The dialog could show previews of other figures related to the manuscript. A good idea, by the way.
The folders do provide context, and I think this could be used when migrating to Nepomuk. The files that you save with the old dialog do not have contextual information but maybe this information could be generated automatically based on file structure. There is a risk, though, that some of the generated annotations would be nonsense.
There is one reason why I think the dialog should save the files in some kind of a folder hierarchy, namely backward compatibility and portability. What if you want to switch to Gnome or you buy a mac? What if the Nepomuk database gets deleted or corrupted? You don’t want to end up with a single folder with a million files without any contextual information. I think the save dialog could save the file in a folder based on the annotations by using some heuristic thinking. The problem would be of course that you might end up with some files in the folder manuscript/figures and some in figures/manuscipt and some in manuscript/results/figures etc.
I agree with this. However, I think this is very hard or impossible to realize. I have an image which appears in several of my papers. Currently, there is a copy of the image in each folder containing a paper which uses the image. I imagine that in the Nepomuk world I will only have one copy of the image which will be linked to all the papers using tags. If a folder hierarchy exists, then where must the image go? Furthermore, LaTeX’s \includegraphics command expects the image to be in the same directory or expects to receive a path to the image’s file name. In the Nepomuk world, how must I figure out that path? If all files are in the same folder, then you can just specify the file name and \includegraphics will still work.
Now that this issue is raised, it occurs to me that in the Nepomuk world all file names must be distinct. The location of the file is not known to the user, so distinct file names is the only way to make a distinction between files. However, I have two courses (in several versions for each academic year) with a main file “course.tex” and the chapters are in files “chapter1.tex”, “chapter2.tex”, … Since the courses live in different directories, there is no clash between “chapter1.tex” of the first course and “chapter1.tex” of the second course. In Nepomuk this will not be possible anymore.
Well, actually this is exactly why there still needs to be some support for physical folders. There is a lot of software around that relies on physical folders. There were already a lot of good ideas as to how one could automatically create physical folders based on annotations and metadata. This is surely something that needs to be tackled as soon as the initial implementation is done.
If you look through the comments to all the “Semantic Save” posts you will find many concerns regarding this topic and many ideas also.
The idea sounds interesting, prototype … seems a bit crowded. But what if the second listbox (the one with the possibilities for what I typed in the textbox — in your example, the one that says “semantic”) only show up floating right below the textbox after I type something, like the options of a combobox, you know? Would clear it and give those options only when needed.
I’d also put the textbox above the first listbox, with an idea of adfing semantic content and it goes down to the list.
Keep up with this work, sounds promissing.
I wrote exactly that in the comments of the image. :)
When it comes to tagging, I love Zemanta approach. It analyze our text as suggest what annotation can be attached. And it’s not in dropdown. It’s visualize in toggle button we can click which one to apply.
I’m rooting for these semantic thingy. Go nepomuk go!
That is yet another thing to integrate: the text analysis. We only have two problems so far: 1. it its computationally complex when done properly, 2. the file dialog api does not provide any means for the application to provide the text. So this is something I see as a second step once the rest works fine.
Much much better! looks very promising!
I can see 2 little problems – can be adressed later:
1. Document-type drop-down menu is small – what if someone create long document-type?
2. When quicksaving, last populated fields will probably be filename and / or document-type. The Ok button should be the nearest of those fields, not the Cancel button.
I would move Ok in place of Document-type (cancel below ok) and Document type on the right of custom widget from clients.
You got me confused because you have separate views that has the same usage. I propose merging the ‘already added’ view and the ‘type text to…’ with a group box or something similar.
It looks very nice now, just one little thing, that has not been said already:
I would recommend removing the frame around the “already added metadata”-view. That would simply make the UI a (probably quite crucial) bit cleaner.
Another thing:
I would make the suggestions-view for adding information a real autocomplete-box, maybe like the awesome-bars in fiefox and rekonq. That would allow to put more information in the sugestion and make it look like something different than a autocompletion.
Pingback: Nepomuk – What Comes Next | Trueg's Blog