Sunday, March 4, 2012

Taking Care for Details

Frank Reininghaus already wrote about all the 4.8.1 Dolphin-bugfixes we've done, so I'd like to talk about just one specific fix: It is "only" about some visual improvements regarding the layout of items when turning on the grouping-feature, but the interesting thing is what happened behind the scenes.

It started when Martin Zilz from kreativkonzentrat wrote me an e-mail a few weeks ago with some suggestions how to improve the look of group-headers. The base of discussion was the following state:

Beside the group-headers Martin also recognized other issues with the layout and it required several internal adjustments in the view-engine to achieve what Martin suggested. But after sharing a lot of e-mails with updated screenshots and doing some finetuning in the code I'm really happy with the end-result:

But beside the icons-view we also adjusted the group-header for the other views. Before the changes the compact view looked like this:

After following Martin's suggestions it looks like this:

The details-view is something where I'm still not 100 % happy, as the alternate backgrounds don't work well together with the grouping from my point of view. However I'd say the look still has improved from:

to:

The main reason why I've written a blog-entry about this bugfix is that it should be an example of how an application can get improved when working together with skilled designers. As developer it is tricky to think outside the boundaries of your own implementation. E.g. I never thought about the vertical lines in the compact-view as the height of the group-header widget was only around 20 pixels. Martin was able to think outside those boundaries and in the end it was not tricky to implement. I had similar experiences when working together with Nuno and Hugo from the Oxygen team. Although many users probably won't see the difference in the first sight I believe those details matter to have a comfortable user experience.

24 comments:

Anonymous
said...

Thank you - the icon view grouping has been bugging me for long time (and this might sound silly but that combined with the comparatively odd wrapping of "long" names of folders has been a major source of resentment towards dolphin vis a vis Konqueror).

I don't use grouping, but that looks much cleaner, than it was before.

One more question: in grouped details mode, why isn't each new block started with an «alternate» background instead of a «regular» one for the first row, so that the header could be on different color from the first row?

As it is now, it may look like the header belongs to only the first row (they share the same background, and the second row has different background).

This is definetly a big impovement. Thank you. Dolphin was one of the main reasons why I fell in love with KDE and it keeps getting better.

Is there currently any plans to improve the search interface? If implemented correctly it could be a true killer feature for Dolphin but as it stands it's terribly lacking especially compared to the rest of the application.

@Skovoroda Nikita:> One more question: in grouped > details mode, why isn't each new > block started with an «alternate» > background instead of a «regular» > one for the first row, so that the > header could be on different color > from the first row?

I initially had it the way you suggested but Martin told me that doing it the opposite way makes it a little bit less cluttered. It depends a little on which kind of content is shown...

You wrote that you are not completely satisfied with the look of the detailed view when in grouping mode. Perhaps it could be improved if the group name would get a different background color. This way you could start the first entrie of every group with the same background color, but you would avoid the clash of the same background color from on group fo the next, for odd numbers of elements in the first group. I could imaging that this is what bothers you.

In general I like the changes, but in the detailed view, are the tree markers allways drawn? I feel like it is pretty clear to which group an entry belongs, since it is indented, and the tree markers look a redundant to me.

@Peter Penz:> I initially had it the way you suggested> but Martin told me that doing it the> opposite way makes it a little bit less> cluttered. It depends a little on which> kind of content is shown...

Yes, that's probably right. For example, starting with alternate row can make things look worse when the last row of the previous group is on «regular» background.

This is a great example how making use of different text contrasts (black/grey) can lead to visually really pleasing layout. All KDE UI developers, look at this! Too often KDE UIs just vary between bold and normal text and too often it's the wrong way around: the less important text is in bold (such as the group headers in you old version). In general I think one should be really careful about using bold text or not use it at all.

Hi Peter, thank you for this sum-up. It's been a real pleasure to work with you on this and it's great to see the results and the feedback from the KDE community. Hope we can improve even more stuff in the future :]

Search might be a good start for further improvements, as i find myself never using it (there must be a reason).

I tried it and it is really better. I like how the columns are resized and displayed. The column view is now usable for something else than the open file dialog.

While you are working on usability. What do you think of finally allowing the icon view to have subbuttons for each app the document can be open with? It was in the original mockup and while it was initially rejected, I still think that with big icons, it can work.

If it it still too confusing, why not splitting the item in 2: view and edit/author? Freedesktop probably does not support this yet, but it would be awesome for smartphones/KDE Active. On tablet, you really don't want an app to edit when you don't want to edit. Okular would be fine. Even if freedesktop does not support it, Konqueror once did, so it is probably not impossible to hack something up.

Also, what about integrating filelight into dolphin, or have plugable views?

@Elv13:> What do you think of finally> allowing the icon view to have> subbuttons for each app the> document can be open with?

I think using other applications than the default is not so a common task to justify showing such button on each hovering. Before adding this I believer other actions like rename, copy, ... should be shown instead. However I've no concrete plans for 4.9 to work on this.

> Also, what about integrating> filelight into dolphin, or have > plugable views?

I don't plan to support view-plugins in Dolphin, for this we have Konqueror :-)

What happened with the animations in Dolphin? I installed 4.8.1 yesterday, and the fluid animations, which were introduced with 4.8.0, are gone. Its just like with 4.7 and before. I do not really need it, but it was nice to view.

They are still there but are deactivated on purpose sometimes since 4.8.1 because of the user-feedback we got. E.g. the animations during resizing a window or during zooming only looked fine when having a few items and I guess those animations are what you are referring to (?).

I had a short comment on Dolphin in one of your old blog entry (probably too old to be read) :-)

I have always been wondering about the startup performance of dolphin. It is not "slow"(maybe ~0.5s), but just isn't as snappy as the MS File Manager (it just pop-up). Is there any plan to improve upon this area?

I know everyone is saying Windows is cheating and pre-load a copy of the File Manager. But then to be fair, even with a running Dolphin, opening an additional instance of Dolphin window isn't as snappy.

I understand the maybe 0.3s difference won't save you any time practically, but the perception of whether KDE/dolphin is "responsive" or not sometimes lies there... the "Details" :-)

Don't get me wrong, I'm a happy Dolphin here and thanks for all your great work!Abe

@Abe:> I have always been wondering > about the startup performance of > dolphin. It is not "slow"(maybe > ~0.5s), but just isn't as snappy > as the MS File Manager (it just > pop-up). Is there any plan to > improve upon this area?

Improving the startup time would only be possible by preloading Dolphin (as you say), but I don't see a reason why the file-manager should be clarified as "more important" in this regard than other applications. So currently I don't have any plans for implementing this.

> I had a short comment on Dolphin > in one of your old blog entry > (probably too old to be read) :-)

For general questions that are not related to the posted blog-entry please just use the Dolphin forum at forum.kde.org (http://forum.kde.org/viewforum.php?f=222&sid=d279114dbae2d9ce234380dabc6639a6 ) Thanks!

I can't put label beside icon in icon view anymore? In KDE's file browser dialog (when I open or save a file) the labels are on right side of icons. I loved that view. I'm a little sad because of it. Don't follow the Gnome way!