… implementations are hard. While I knew that implementing the semantic save would not be easy I did not think that simply converting the mockup to an actual dialog would be this annoying. It just does not look great. The two screenshots below show the small and the expanded version of the dialog and I am not thrilled.
It just does not look like a dialog I would like using. Way to plain and boring.
Thus, I figured I would remove the description section altogether and only show the annotation listview once information has been added. That would allow me to only have one version of the dialog which is expanded only when required, ie. when there is information to show.
As for the description/comment: I figure one could simply use the same line edit as for the “add information”. That line edit uses auto-completion anyway and the probability of the text being a comment grows with the length of the text. Imagine a line edit turning into a multi-line text edit as soon as the user types more than fits into the one line.
Anyway, that is the state of it: I am trying to make it look less ugly. All the fancy automatic folder handling a lot of you discussed in the last post will be the topic for Semantic Save 3.0, once I managed to get this baby to work (we well as its counterpart the semantic open dialog).
Trueg's Blog 
Wow, this is simplistic! Just the way most of the users would like to I guess. Yes it is boring but….why should a -SAVE- dialog be interesting on the outside? Please answer me that question ;-)
What about selecting file format (not semantic type)?
The point is that the user does not think about that anymore. In most use cases the mime type is fixed anyway. Think about file downloading or saving an office doc.
There are still many use cases where you cannot eliminate the mime type completely. That, however, does not mean that I won’t try. :P
I think save dialog should have two modes: “tradicional” and “semantic”. It’s easy and solves many problems like missing file format combo, Places, iconview with zoombar (don’t forget about users, which don’t use Nepomuk). Of course, the last mode should be remembered.
Well, obviously this dialog would never be used on systems which do not use Nepomuk.
I still think a folder view approach would be better, clicking “projects” folder is still easier than writing “project” in the information.
Hierarchy is also important, it can’t be elimitaded completely, maybe putting another box, with tags that are only related to the tags in the main list, so if I have the project tag, only show the projects in that list. So the list can keep getting smaller
Let’s look into the hierarchy issue based on an example.
Say I am used to save screenshots for the “semantic save dialog” into folder “nepomuk/semantic-save/screenshots”. If I understand correctly this is the kind of hierarchy you want to be exposed instead of choosing project “Nepomuk”, application “semantic save dialog” and type “Screenshot” separately.
In the semantic world, however, you would only choose two things:
1. The type: screenshot
2. The depicted application
The relation to the project “Nepomuk” would already come from the application which is a part of “Nepomuk”.
So there is two things to choose instead of one (the folder).
How could the choosing of the type (screenshot) and the depicted application be made any easier (ignoring that in this case the saving application could already provide that information automatically)?
Would we try to learn and propose certain combinations that have been used before?
Or would the user define groups of relations?
The problem I’m posing, is that some users (including me) don’t remember what’s in their computers. I usually have to browse through the folders to know where to put things.
One solution is to be able to browse through tags just as folders, but it would end up being the same as folders, only different name.
Another solution would be to have tag suggestions, like after entering “type:image” the user is presented with, “image categorie:” automatically added, waiting for some data, and showing all possible image categories (wallpaper, friends, family, etc).
For the type, the document type I would imagine that for predefined ones we would have typical mime types. For user defined types we would make use of the type hierarchy and previous usage. This means that if you save an image you do get such choices as “screenshot”, “photo”, “wallpaper”, and so on. But not something like “invoice” in the default list. This would already simplify the selection of the document type considerably.
As for suggestions: these are always hard and tricky but definitely something I want to do and already worked on in the past.
Selecting the depicted application in the example I provided would still have to be done manually though, but it should be guided somehow. That means we need a browser for these resources anyway – and that is needed for the opening of files again. I propose this: I will start with the simple version which does the filtering I mention above and provides auto-completion on the annotations. Then I will start the discussion on the opening dialog which will directly involve the resource browsing, which can then be used in the save dialog again.
(BTW: just to be sure we are talking about the same thing: “friends” and “family” are not image types. They could be people groups and images could depict people in those groups. So you would not categorize an image to be in such a group. You would rather state that this photo depicts this person who in turn is in that group of people or part of some project or who attended some event and so on…)
As long as I can have the possibility of browsing through tags, I’m happy, I will keep thinking about it and give some more suggestion/ make mockup when neccesary, thanks for the effort.
About friends/family, you’re right in tags, that becomes simpler than in folders. The real potency of tags, comes when the apps fill in them, like digikam putting the people in the pictures, after recognizing the faces.
When you save something, you need to know how to retrieve it later. This information should be in a visible place IMHO. I’ve quickly made a mockup on http://kimsakkat.free.fr/semanticsaving.png
While I like your mockup most of the information you show is not available before saving the file. But already added metadata should indeed be visible. That is the point of the first view. I should add some example data…. stupid Qt designer is not working at the moment… does not allow to add any widgets.
It was just to explain the idea: whatever datas/metadatas later used to retrieve the file, should be visible on saving dialog. I’ve put these informations on the left, but I think it should be on the right. Because the left part of the dialog box is a good place to put some quick icons for document types or folders (as it is currently).
PS: I used the Firefox Pencil extension to draw it.
I might have done something better here: http://kimsakkat.free.fr/semanticsaving_like_traditionnal_look.png
The idea is to look more like a traditional save as dialog. Annotations and informations fields are supposed to open in the metadata shape. On the left, it is a place for favorites types of files and folders. I’ve added the type drop-down menu in the metadata shape, but it could be placed below the filename box.
Very interesting. So the left hand links are places as we have now to change the folder setting on the top? Or do these “places” on the left already contain additional meta-data like the document type?
Only 4 buttons and multiple input-areas. I JUST WANT TO SAVE A FILE! ;-)
I still vote +1 for a very minimum dialog you can extend with such things as places, extra input fields, details, tags and what not. Most of the times I want to save a file (and I know where I want to save it) and MAYBE I will give the type of content. No more, no less.
+1 on places at left in ‘Advanced’. Places are very user-friendly and keep the system organized.
+1 on using Places for the drop down in the Minimum dialog.
I understand we can do many things with Nepomuk and such but developers should understand that cool features are not always features that make KDE better for mainstream use. As we want to make KDE grow, we really should look at what a mainstream-user would like. Having 20 buttons, 15 checkboxes and 12 input fields isn’t one of them.
I agree that we do not need tons of buttons. However, looking at what the mainstream wants does not work in this case since most users are so fixed on folders that they have a very hard time imagining anything else. Even for us that is hard. Thus, I still think that we need to try something new here even if at first glance it might confuse users.
There is a contradiction here :-) I agree that places are very user friendly, so they shouldn’t be hidden in ‘Advanced’.
Thanks for you interest.
In the idea, the left hand links are created by the user putting in his favorites places and document type (that allow quick saving). But some cool links should be pre-populated, because just as we currently have Documents, Music, Videos, etc. paths in KDE we could have similar settings with document types.
In a user point of view, I think its important to have the choice to save some files with folders and some others with semantic or with a mix. So the place on the left sould contains both folders and “semantic links” (and as someone suggested, may be a folder could be associated with meta-datas).
I reworked a bit the dialog:
Purpose is to reduce mouse movements, help user to not chose folders (its small and greyed) and to look familiar but different (to help notes the difference).
I’ve also added the prefered apps for opening the document, which I think is a big missing even non-semantic save dialog
I like it. Already looks much better than mine. :)
I figure the “places” could be conditions on the storage folder and/or the metadata which might even be combinable in the case of metadata. As such they would slightly differ from the current “places” which only change the folder.
Maybe Dolphin should ask if Nepomuk has to make an label when a folder is created?
If we use the original Places it should be located on the left. Otherwise the right might be an good option. Check the guidelines.
I’ve put it on the right because, like you, I just want to save. With places on the right, I just need to select something in and clic ‘Save’ button which is near.
The other reason is really to disturb users: it looks familiar but there is enough differences for letting them think a bit.
But there is room for improvements: what about Save button below places, or file types / file sorting entirey in places instead of a drop-down, etc.?