Like many other things, okular used the sidebar KPDF had, adding tabs with new stuff (like the Review pane and the Bookmarks panel).
Now, the problem is that the implementation for these sidebars was all but a real solution. In the past, and especially yesterday, our usability expert Florian pointed me the issues of it.
For example...
- Too much space taken by the tabs of the toolbox (thus, less space for the real contents of the tabs)
- "jumping" tabs - that means, the "label" of each tab had a different position, depending on the open ones (of course, not for the first)
- No way to change the active tab of the toolbox using the keyboard (that is what was also reported by the KPDF's bug 132152
- not really good-looking (not a real issue, just a taste that many people made me notice)
[image:2921 align=right]
So, Florian suggested me a new possible solution, and asked me if it would have been doable. I said "why not?", and instantly started working on it. Luckly, it was not really difficult, and the result is what is see on the right. Nice, isn't it? 
This new approach solves basically almost all the "cons" of the old sidebar, and introduces some new thing:
- Every tab have the full window height for its contents
- You can activate each tab from a well known position, and using also the keyboard
- You can close the active tab with no need to close the way to select one
This means that you can click on the icon of the current tab to close it, leaving more room for the contents area, without closing the tabbar! - A better look for it (sometimes is due, isn't it?
The only "regression" the new sidebar introduces wrt the old one, is that the only way to distinguish every tab is looking at its icon, while with the toolbox there was also the name next to the icon. Partially solved by providing the name as tooltip of each icon.
Still some graphical glitch is left (like the color for the disabled tabs), but they are easy to be solved, and I hope to fix them in time for KDE 4.0 beta2.
As usual, comments, problems and ideas are always welcome!
Syndicate Blogs
Nice
I like the design. Better than the old kpdf one.
I help with a gtk application, and we provide something like this with three variants:
1/ the icon view as here (also with tooltips): http://www.gramps-project.org/wiki/index.php?title=Image:Gramps_sidebaricons_filter.png
2/ the sidebar with small icons and text:
http://www.gramps-project.org/wiki/index.php?title=Image:Mainwin.png
3/ the sidebar as horizontal tabs: http://gramps-project.org/gramps-manual/2.2/en/figures/noside-nofilt.png
Experience has learned we need to ship the default version with 2/, as too many new users just need experience to understand what the icons are for, and find the program to confusing/difficult with just the icons.
Advanced users however switch to 1/ or 3/ to make space for more data on the screen.
In conclusion: I think you should offer icons with text as default, with the option to easily drop the text and clear up space for more experienced users.
previously, you could hide
previously, you could hide the toolbox so that no space was wasted. i'm not sure but from the screenshoot it seems that this won't be possible anymore (seems you could hide the bookmarks and table of contents widgets, but the icons will keep wasting space). am i wrong?
also, the widget that shows the page number and has the previous/next buttons (at the bottom) seems to be innecesarily large. why not make it a toolbar (with resizable icons)?
regards.
previously, you could hide
previously, you could hide the toolbox so that no space was wasted. i'm not sure but from the screenshoot it seems that this won't be possible anymore (seems you could hide the bookmarks and table of contents widgets, but the icons will keep wasting space). am i wrong?
Don't worry, it's still possible to hide the whole sidebar
also, the widget that shows the page number and has the previous/next buttons (at the bottom) seems to be innecesarily large. why not make it a toolbar (with resizable icons)?
Moving the "previous page"/"next page" stuff into the toolbar is a very delicate matter. Toolbar space is limited. Especially with the new default that shows the text from the respective menu entry below the icons. Currently there is no way to set the icon label to something shorter like "Previous"/"Next" without at the same time changing its menu entries. Pick a language that uses more letters it even gets worse: In German it is "Vorige Seite" and "Nächste Seite". Combine this with the "Navigationswerkzeug" (that's "Browse Tool" in German) and the toolbar will be unusably wide. What started as a very good idea usability wise (combining text with icons) is currently preventing us from putting into the toolbar what should be there.
Until this issue is resolved I am afraid there is nothing I can do.
i like the old one better
Are you only showing the top-left of the screen because otherwise we could see the wasted space below the icons?
No, seriously, I like the old approach better. It might have some cons, true, but every solution does.
Cons of the new solution:
- I don't know what the icons are for. Thats a big problem.
- Screen space wasted both horizontally and vertically.
It also looks a little like kontact now. Not that this is a problem...
I hope my text is not too critical, these are just my first thoughts. Thanks for your work on okular, pinotree!
Vertical space
The big problem of the old solution was the much space used by tabs, wasted.
Wasting vertical space is something I don't want, especially as it's much "expensive" than horizontal space, especially if you have a widescreen display. In that case, wasting 60 pixel in the horizontal dimension is quite "cheaper" than wasting 60 pixels in the vertical dimensions. In fact, I often see people with a widescreen display (usually modern laptops) placing their kicker/panel in the right side.
Oh, and the "wasted" space below icons can be filled by more icons of new tabs (in case), with no more vertical space loss like using a toolbox would imply.
Usability?
Not such a bit fan usability wise. The icons give no indication as to what their function is, which is one of the reasons why KDE4 is adding text to all the icons. A sidebar like Amarok's would/could work well here I think.
Ergonomics can save your neck ;)
Amarok uses vertical text in its sidebar tabs, no?
Vertical text and memory
Yes, Amarok uses vertical text here, but as eean makes a note of, at least it is actually there
i shall attempt to list the reasoning behind it:
During the 1.2 release cycle we did a huge amount of experimentation with regards to the optimal sidebar solution for Amarok, and the current was what we ended up with.
We tried out the QToolBox system, which was discarded extremely quickly, because a nice, quick little calculation provided us with a number "200", which is the number of vertical pixels the tabs took up using that method, and since we required a large amount of vertical space for the data in the browsers, that was just not an option.
Then we tried the KJanusWidget (the sidebar used in most configuration dialogs) and though it did seem like the most userfriendly on the surface, it meant that we would lose a good 50 pixels of horizontal space, something we also needed for other information.
We then decided to go back and try the old sidebar again, but in stead of having the old solution (which was to have only the current tab have text, as it works in Konqueror's sidebar), we tried adding text to all the tabs. One large problem popped up very quickly: Some of the most used widget styles did not distinguish between active and non-active tabs, and as such this solution was useless in the real world.
Furthermore, in the widget styles that /did/ distinguish between the two states, often you would end up with the problem that because the method used was to use bold text, the tab buttons would jump around on the screen, and as such you could not depend on the position of the buttons to be the same at all times (this was of course also a problem with the original Konqueror-like method).
So what we did in the end was to extend the KSidebar widget with an entirely new sidebar view mode, designed in part by yours truly i am proud to say, which incorporated muscle memory in a much higher degree, and which used animations and highlighting colours to show the states of activity in the sidebar.
Now, people will complain (as is done here and was done back when it was implemented) that the icons are too small and the text is vertical and as such not so easy to read. Well, we decided that because Amarok is a program designed for very frequent use, people will very quickly get used to the position of them; that is, use the text as an initial guide for establishing the memory, then use the icons (and the length of the text) as memory aides, and finally, for normal, every-day use, make use of that muscle memory and visual memory aides to make the choice of which buttons to press.
So... people trained in classical usability will have a fit first time they see the sidebar, but really, it was not just something that was decided one night when we were out getting drunk - it was a long, experiment-driven process, aimed very directly at producing the most efficient result for the specific use cases in Amarok
Wether these use cases can be transferred to okular is not something i will comment on, having not even tried the program - but i thought it would be good to clear up the decision process behind the Amarok sidebar
P.S.: Sorry for the very long reply, but i couldn't really make it any shorter
Re: Vertical text and memory
Before really replying you, I'd like to remember all that the new interface is not set into the stone, neither 100% done
I think that we can't really compare the okular and Amarok usecases, and I'll explain my reasons.
With Amarok, you start it, and you have to do some _necessary_ steps to make it really working: your the folders with your music to the collection, create it, create a paylist, and finally play. In that meanwhile, you have all the time to get familiar with the interface, that initially appears empty, holding no real data. From what I see, Amarok is not really the application to use for "double-click on a song, play it and close".
Okular, instead, is usually started as a result of an opening action within a file manager, so the user sees an application popping up holding their document. The user has no time to get familiar with it, the interface should not scary them, but give a straightforward and immediate overview on the main parts of it.
Of course, there's also the fact that the user learn the interface from time to time, but that's something I don't want to rely on (like you Amarok guys do).
Decision process... mostly it's what I talked about in my blog entry, with also a glance on usability. Yes, because now we have an application that is (excluding the annotations part) almost entirely (if not 100%) navigable through keyboard, and that's something really important for us, and we have lots of users just using the keyboard to read their documents.
Amarok's tabs
From what I was told by our usability expert, vertical text has the drawback of being read vertically, while the associated icon is horizontal, and this can create problems.
Futhermore, Amarok has a really thin sidebar, so it's basically impossible to know what a tab is for, just looking at its icon (thus you need text), while ours has 48x48 icons that should be straightforward to understand.
Regarding the sidebar of Opera: if you take a kruler, you can easily notice the size of Opera's and okular's tabbars and sidebars are basically the same. So, if you like Opera's sidebar, you will lke okular's as well
About color and style: with the current implementation it should be quite easy (artistic touch excluded
) to make the icons look like "joined" to the side tab.