Back in 2009 Alessandro Sivieri worked on a GSoC project to create a new way of saving and opening files – the semantic way. Sadly we never finished his work by integrating it into Nepomuk properly. I, however, still think that his approach was sound. The problems back then were some missing features, performance, and a rough GUI.
I thought about trying it again for a long while, mostly because I simply want semantic saving. Today I finally sat down and created a mockup of the Smart Save Dialog 2.0. Here goes:
The idea is simple: instead of choosing the folder you want to save in (yeah, yeah, there is still the possibility to select the folder anyway) you define information and relations around the document. This includes an optional title and description (could be pre-filled by the application in the future), a document type (Here a type is neither a mime-type like pdf or an NFO type like nfo:PaginatedTextDocument but rather a real-world type like contract, invoice, paper, thesis, and so on. The idea is to let the user define new types and maybe even share those types with others.), and a set of additional annotations. The latter can be anything, starting with simple relations to projects or people but can also be literal properties (this is where I aim to revive my nepomukannotation framework by solving its performance issues).
Anyway, I created the mockup and did not want to let it go to waste. Thus, I blog about it. Maybe some of you have ideas on how to improve the dialog. But please no questions about how to disable Nepomuk or how you do not want such a feature!
Trueg's Blog 
Just want to understand it correctly; it’s meant as a replacement for the current save dialog, enabling to save all kinds of files with some annotations? Or just to add annotations to an existing file?
In the first case, I would say it’s worth to replace the lineedit with some kind of minimalistic file view inside the dialog. In the later case, I think the lineedit could be removed.
(Oh, and I really love to change fodlers)
The former: a new save dialog. Which line edit are you referring to?
I was thinking of the folder selection-thingie (I see now that it’s not a lineedit, sorry). I would make it either a full file selection dialog (similar to the normal file saving dialog) or remove it if the goal is to have things saved based on annotations instead of filenames. I think that the current “compromise” does not really fit in with the rest of the dialog, but then I’m far from someone with good design opinions.
Saving files this way, without paying attention to classical folder organization, will make a person’s files painful to locate if accessed by a desktop or a command line interface that does not support nepomuk.
Tagging needs talent, maybe more than folder selecting… But, If I had these options I’d serenely like use them!
bah, fuse to the rescue. ;)
I like it. Though we should think about getting rid of saving altogether, like Apple did with Lion…
Certainly interesting but on another level I think.
> Tagging needs talent, maybe more than folder selecting
Given that I consider that folders names are tags, I disagree: it’s the same thing, one is (mostly as soft links exist) hierarchical, the other is not, that’s all.
Interesting but it need some work. Because I can see some problems for non-geek users (I’m a sysadmin):
– They will not understand that they can forget the “folder” part.
– Too much informations needed, I think. What about quick saving?
– How to deal with multiple users sharing files? they will need to define common annotations, but this can became far more complicated than folders / sub folders hierarchy.
– The “folder” selection is actually optional. I would be perfectly fine with making it even smaller and harder to find though – maybe a single button.
– All information is optional, quick saving means: press enter or click on Save. You can still find your file via its content and its date.
– Common annotations is a problem indeed but a typical semantic web problem for which there are standard solutions.
I propose find some participates for an experiment: use a special kde software spin that does NOT have ANY access to the classical folder/subfolder system, with a save dialog like this one, and a Dolphin with only searching and tagging ways to find files…
I’d like to get experimenting…
Good idea.
In terms of technology, I think it is C O O L ;)
However, when it comes to every-day usability, there is a major show-stopper for me: What about migration? My current documents and files and whatsoever (about a thousand; I can imagine others having more) are not tagged, but organised hierarchically; in order to have one interface to access them all, I would have to tag them all which is quite a lot of work. This seems to be a systemic issue or do you have any idea to work around it?
I just got another idea. In my office environment, people have a common naming scheme for files, like DATE_TITLE_AUTHOR_VersionX.ODT or so. If I add this information as tags, would it be possible to automatically compose filenames using this information? Could be handy.
If you are thinking of “tags” as keywords then what I want to do is a bit more complex. And you can still find your files through the names of the folders and the file names. The file search/browsing is supposed to integrate all that. Of course this is not trivial but perfectly possible. I should mockup opening of files now…
Uhm… Saving is one thing, but how will one find the file again? (Yes, it miaght be a stupid question, but it is the first question an end user will ask).
Beside this it looks promising. Just do not clutter it to much! I’m forced to use Hummingbird DM as a document storage db. It is so versatil that one need from 2 to 3 days training to use it… Please do not go into the same trap :)
Powerful search is indeed far from trivial. I have no better answer for you today. :P
This is an idea which I’ve been wondering about for some time. As someone who loves the idea of tagging, I’m wondering why this wasn’t there at the beginning. With KDE4, I’ve just been ignoring it and resorting to folders.
IMO, something like this is necessary to make ‘semantic’ work. Of course for it to really work it needs features like remembering which program called the dialog and what the previous tags saved with it were, auto-completion?, etc.
Great to see some more work on this. I thought the idea was really promising, but the implementation was not really usable in the end. It would be so great to have this in place.
About your mockup: It looks great.
I assume the arrow besides the Folder element is supposed to toggle an oldschool file browser?
It would be great to have integration with desktop activities.
I’m not sure about the dropdown for document types. It might get cluttered / unclear over time.
Perhaps by default the file should be saved in a hierarchy that resembles the metadata (like ~/Documents/$documentType)?
I really think the biggest complexity is the integration: the desktop should be smart enough to create many metadata automatically.
How would you imagine integration with activities?
Well, perhaps its just a reflection of my personal use case, but I use activities that correspond to the stuff I want to work on (although my discipline is sometimes slipping there). Anyway, it would be nice if I could find all files that I created or downloaded while using the “project xy” activity.
By the way, it would be great if you could import metadata easily. For example I download a lot of papers, which often have names that I don’t remember (e.g. the DOI). It would be great if I could import the common metadata (e.g. the bibtex entry or something).
That would be great indeed. In this case I suppose it has to be done manually, right? Like: “Attach this bibtex to this document”?
This would be just great and the mockup looks pretty good as is. It has all the new useful semantic information with a pretty clear indication of traditional semantics of filename and path.
My thought is that it is better to keep the traditional semantics available rather than attempt to segregate it as suggested by other commenters. It is all just just meta-information about whatever content is being saved. I think the mockup does a good job of preserving semantics the user is already familiar with, while providing new semantics for the user to take advantage of.
I am curious how the Annotations section would work though. It doesn’t appear to be free form text. How would the search work and what would the user be presented? Just curious. :-)
About the annotations:
I have a plugin system in place which does parse the input in the search field and then proposes annotations accordingly.
Obviously the most simple type of annotation is searching for any pimo:Thing which matches the search terms and propose to relate to that.
Other plugins try to parse stuff like: “author:foobar” and map “author” to a property and “foobar” to a resource or literal matching the range of the property.
I would also like applications to provide the text of the document so that the framework can analyse it and use it to propose better suggestions. Basic idea: look for existing things in the text or look up dbpedia for concepts.
More complex plugins are possible. Like looking for annotations that were often used in this context (application, time, mime type of document, etc.)
Tagging each and every file is too much work, even being presented with so many choice each time a user “just wants to save” is too much work.
A better solution could be hiding the tag list, and making it available with a buton, and presenting the old file-dialog.
Hierarchy is needed, for example if I want to save a file related to a project I did last year, I don’t remember if I said, “foo project” or “foo2 project” and so I can’t give an exact tag to relate this file to last year file, doing this would involve: looking for a file of the old project, reading the tags, and then saving the new file.
Please forget “tags” as in “keywords”. This is NOT what Nepomuk does. It never ever did. It is about relating concepts. In this case you would have an actual project resource which you can easily find by browsing your projects and restricting by “used last year”.
I know tags aren’t only keywords, But being presented with all the relations, and all the metadata each time a file is saved is a bit too much, I think it would be better to have it hidden, and that it recollects all data it can automatically.
Also about the hierarchy, being able to see what’s already there helps a lot to know the correct way to organize a file, so a file view (it could be a kio which shows tag resources as folders, is needed.)
For example if I want to number the slides of a presentation (of images) I need to know the previous number, so I need to view all the previous images related to that.
Would you imagine this as part of the dialog or completely separate?
I would imagine it as part of the dialog, because it affects the name of the file
I think if you really want a functioning semantic desktop then you need to have things like this so definitely +1 for me
Agree with earlier poster it should be an optional panel on the save window with a button to toggle and the option to have it always shown
Also think that it should be a right click context menu available in Dolphin (and other file lists) or a tab in properties for existing files
If you install the nepomukannotation package (http://quickgit.kde.org/?p=nepomukannotation.git&a=summary) then you already get the right-click action allowing to annotate files.
Okay these are my opinions:
Just the save dialog:
+ Great to have Save/Cancel buttons
+ Add Information search/add bar
+ Comment box place
* Title little weird as I would mistake easily filename and title (yes, document title can be other than document filename, but file is for people the document)
+ Possibility to choose file type to be something else than what MIME is. Especially if you have a PNG image what is a diagram, it belongs to documents and not photos.
– Folder choosing
– File naming
So I would say, re-think how the directory and filename are selected. What kind dialog gets opened when user clicks the arrow after “Folder”?
What if you would cut the comment part off the dialog? Make it totally optional, a hided one what user needs to click to open. Same way as now GTK+ save dialoge is small and when you click “browser folders” or so on it will slide open bigger?
As so far when I am about to save file. I only want few things:
1. Save file fast (means I get wanted directory open fast from sidepanel)
2. Choose the directory where I save file
3. Choose the filename
And now with the semantik data:
4. Choose tags/annotations/etc from list or just typing them to there.
I dont care about comment so much. As it demands that I summarise the file what I have. And showing it – even if optional – makes me feel I need to invent something there.
And opinions of rest of the system:
I would like to see better search for Dolphin. The sidepanel is right way to go (In My Opinion).
More like my idea http://forum.kde.org/brainstorm.php#idea94385_page1
The annotation/tagging/rating etc should happen from Dolphin sidepanel (if using Dolphin), like now it is possible. there should not be any extra dialog for that.
The file properties window should at least have functions as it has now so you can do it from other apps as well.
So I think those are well tough.
The Open Dialog will be interesting to see. As it should be easier to actually do.
What comes to whole semantic data + hierarchical directory tree, I would say “Never take off the directories”.
As example I need a lot to open file in remote server, save it to my own computer for editing. Edit it later and then save it to other remote place while editing it. So I can not just use filemanager to copy file to other place.
And I like to keep hierarchical very well tidy and logical so I can use it from command line or from remote computer.
Even how much I would love to see a system where I would not need to care where the file is but I can summon it when wanted just with few mouse clicks. I same time hate it as much.
I agree with the search side panel. Something in that direction.
So how about removing the title by default and only showing the comment since actually you are right: a file already has a title – the file name. But a comment is often useful.
It is really hard to say as in your mockup you have covered almost all functions what are needed. I would say there are two camps and they are overlapping, you can not remove something to make other camp feel bad.
I think I have the problem I still don’t fully understand what is the difference with “Annotation” and Tag.
But I will comment on your new version of the mockup
Well, the terms “annotation” and “tag” are used differently in different systems – sadly. For me a tag is nothing more than a keyword, ie. a simple string that is associated with the resource. An annotation on the other hand is anything else, ie. a typed property on the resource like its creation date or its title or the author of the text, or the related project, or the task which has lead to its creation, and so on. An annotation has semantics understandable by a computer while a tag is just a blob of text which only has meaning for the user.
Some notes:
1.) Giving semantic meaning to files in the save-dialog is awsome.
2.) The ability to add keywords is not bad either…just like emails and photos
2.) Does an average* user fill in extra information most of the times? I guess not. So maybe you could slim the design down to: filename, location and type
Mockup: http://imageshack.us/photo/my-images/831/mockupfiledialog.png/
*I know there is not such thing but we all know what is meant by it.
A simple view sounds interesting. However, I do not want to expose keywords too much as they are not what we want to achieve here.
Pingback: Semantic Saving – Next Next Try « Trueg's Blog
Why save dialog should be a dialog in first place?
In most cases save dialog block window behind, so the dialog could be almost the same size as the parent window without using any additional space :)
If we could think about save dialog as a big element – http://bit.ly/mQEKlC
What I tried to do, was to remove as many buttons as possible from the UI. Only the SAVE is most important here.
For semantic meta information a unified element could be used (no gap b/w exiting elements and input saves vertical space, also looks quite nice). To make it easy to understand – basic icons on the left side are added next to each element.
On hover a background color for single meta record could change, as well an X element on the right to remove the record.
For styling, QML supports SVG, so I hope some custom elements could be created (and hopefully later merged to the KDE base)
It looks great and I hope we can so some of the nice inline things later. For now I will stick to plain widgets since that is what I know and the data is more important. But I would be glad about any help in that direction (never did any QML myself for example).