Reply to topic

[Design Project] System Settings

User avatar ken300
Registered Member
Posts
314
Karma
0
One suggestion that might make the 'Scrollarea' option even easier to navigate would be to just move the 'Advanced' arrow from the right hand side of the screen to the left so that it's nearer the sidebar where you've just clicked and you're not moving the mouse from one side of the screen to the other.

Also i think the 'Simple'/'Advanced' text below that arrow might be better as just 'Show'/'Hide' or something.
User avatar Heiko Tietze
Registered Member
Posts
593
Karma
0
OS

Re: [Design Project] System Settings

Sat Jun 14, 2014 10:41 am
kdeuserk wrote:+1, best variant so far, imho. Maybe Heiko could include this in the survey?

Running surveys must not get modified. And finally we have to decide on our own which layout fits best.
User avatar Heiko Tietze
Registered Member
Posts
593
Karma
0
OS

Re: [Design Project] System Settings

Sat Jun 14, 2014 11:00 am
CTown wrote:What if results from every applicable module were included but the results prioritized the stuff from the module the user is currently in? This way search will be more optimized if the user has a general idea where to start looking; which is not a strech since the KCMs will be reorganized.

The question is how search should work at all. Does it create a new page with all results (or just a list as in your proposal, similar to krunner) or is it some kind of highlighter emphasizing the sections with the search term? Furthermore, I want to look for all items that might concern security when I look for 'password'. That could be realized by adding search terms to sections, which are accessed on search additionally to the labels.
About the final design I'd fully trust in anditosan's expertise and creativity :)
CTown
Registered Member
Posts
40
Karma
0
OS
Thanks for the kind words ken300.

Heiko Tietze wrote:
CTown wrote:What if results from every applicable module were included but the results prioritized the stuff from the module the user is currently in? This way search will be more optimized if the user has a general idea where to start looking; which is not a strech since the KCMs will be reorganized.

The question is how search should work at all. Does it create a new page with all results (or just a list as in your proposal, similar to krunner) or is it some kind of highlighter emphasizing the sections with the search term? Furthermore, I want to look for all items that might concern security when I look for 'password'. That could be realized by adding search terms to sections, which are accessed on search additionally to the labels.
About the final design I'd fully trust in anditosan's expertise and creativity :)


Yeah, I agree with that last part. Anditosan's work has been top notch!

In the current System Settings Level One was a wall of icons to represent Level Three modules (such as Hardware/Printers). This made highlighting the correct submodule very useful. However, in anditosan's mock-ups, Level One now shows Level Two modules in a way to be clean and very descriptive. So, I'm not sure if highlighting anything here will very helpful.

Also, in the current System Settings, unless a module provides its own search, then that module has no search function. For instance, "Colors" has no search options. However, thanks to anditiosan's work, we can now do search in an extremely consistent manner. For instance, here is a mock-up to show when searching for "inactive window colors" while in "Colors": (Note that the white boxes that I used are just place holders for the content from anditosan's mock-ups that I didn't include, just out of laziness. Same for the icons, I just pulled these out of the mock-up toolkit.)

https://www.dropbox.com/s/7bfe9uw10menk ... indows.png

I think this works because the Search bar is on the opposite side of the sub content in anditosan's mock-ups. So, we can show results in a page without getting in the way of actual content and highlight if necessary. An example module that includes its own search is KWin's Desktop Effect module. I think this idea even works for that module:

https://www.dropbox.com/s/imzaxp5wpib6r ... ffects.png

I believe you are thinking of tags, Heiko? In order to make searching easier, the back-end should allow tags to be attached to each section or subsection. Synonyms can be included in the tags as well. These should be translatable as well. I don't expect that these tags would be viewable by the user.

Well, I hope this suggestion sounds reasonable.
User avatar Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
In a browser-like design I would expect the search within the current 'window' below the scroll area. That's what we call highlighter (cf. threads about 'New Search for XY'). If there is a highlighter to get fast to the right place in the current section (that is an expanded second level), do we really need a search? Doesn't it makes more sense to have see-as-well links for cross-module access? On the other hand people expect an advanced search (http://user-prompt.com/kde-system-setti ... avigation/ look for 'struktured' or 'David Ellis' at the comments).
User avatar ken300
Registered Member
Posts
314
Karma
0

Re: [Design Project] System Settings

Sun Jun 15, 2014 10:47 am
My vote would be for having a good search like the one that Ctown suggested earlier.

I took away from reading those comments that you mentioned that maybe we should optimise navigating with the mouse for more advanced users who know where stuff is (so minimise distance between clicks and make speed of navigation a priority) but have a search function aimed squarely at casual users with little concession to how good it'll be for advanced users - it doesn't sound like it'll be a hit with them anyway!

If that's the route we go down then we want navigating with the mouse to be as slick, fast & simple as possible and IMHumbleO that means Anditosan's scrollarea prototype with the white space along the top (as he'd originally suggested) to draw attention to the search field if people want to use that.
User avatar Heiko Tietze
Registered Member
Posts
593
Karma
0
OS

Re: [Design Project] System Settings

Sun Jun 15, 2014 10:54 am
I'm not talking about mouse or navigation. Search could be replaced by a highlighter, which is similar to what you have in browsers per ctrl+F. Just an idea to explore the options, not yet a suggestion.
CTown
Registered Member
Posts
40
Karma
0
OS

Re: [Design Project] System Settings

Mon Jun 16, 2014 12:55 am
Heiko Tietze wrote:I'm not talking about mouse or navigation. Search could be replaced by a highlighter, which is similar to what you have in browsers per ctrl+F. Just an idea to explore the options, not yet a suggestion.


Oh, that's what you meant by a highlighter. I thought you were referring to the feature where typing something in the search bar grays out modules that are not relevant to the search term:

https://www.dropbox.com/s/4qnl9v0l6re6ged/users.png

One option could be to include a separate filter bar per module as you suggest. The benefit of this is that any module would work as a standalone module very well. As seen here, a separate highlighter seems to work well:

https://www.dropbox.com/s/4d3tkvtruxw8q ... tusBar.png

However, I think highlighter functionality could also be added to the universal search bar (which current System Settings lacks). It keeps things clean and tidy. Also, if a user is looking in the wrong place for something, he or she can still be guided to the right location.

https://www.dropbox.com/s/zhct75egjplc3 ... ighter.png
User avatar ken300
Registered Member
Posts
314
Karma
0
I fully understand that the 'filter' and ' search' are two entirely different things but to any casual user a text field for filtering looks much the same one for highlighting or searching. What about combining the 'Filter', 'Highlighter' and 'search' fields into one something like this:

http://element-6.deviantart.com/art/Com ... 1402906826

When i'm typing a search i wouldn't expect the results to appear until i hit 'enter' anyway, before hitting 'enter' the search field could just act as a filter / highlighter.

Advantages:
* Reduced visual clutter
* Users wouldn't be thinking 'which one is search & which is filter' - especially casual users who aren't yet aware of 'if it's at the bottom of the window it's a filter' (or whatever the rule will be in the future)
* It would feel modern IMO - a bit like chrome's 'omnibar' where the search field and address bar are combined, it works well (at least it does on my android tablet)

Disadvantages:
* The combined 'filter & search' field would only be available if that module was contained in the full SySe window - if it's opened outside SySe then either the filter would need to be provided in some other way or you'd just have to do without a filter
User avatar Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
CTown wrote:I thought you were referring to the feature where typing something in the search bar grays out modules that are not relevant to the search term

ken300 wrote:...but to any casual user a text field for filtering looks much the same one for highlighting or searching

I guess there is some confusion about the idea of separating those functions. We discussed this guideline in the last weeks, culminating in the thread about KMail (viewtopic.php?f=285&t=121598). The goal is to unify all three (or four) options: Highlighting works similar to the current SySe function but does not gray out items but jumps to the first occurrence (like Kate/KWrite/Konqueror, or the like). Filter creates a subset of items, works immediately, and is distinguished into dynamic and static which means user can switch it on/off or not. And search generates a complete new list, not necessarily based on current context only.

Your proposals work like KRunner and would not fit well into this guideline (of course we are free to do diverge from the not yet decided standard). But I wonder if a search is really necessary. All categories are shown at the top, all sections can be reached by the highlighter, so we just look for stuff outside the current context. And wouldn't a perfect list of links to other topics ('see as well') solve any question?
User avatar ken300
Registered Member
Posts
314
Karma
0

Re: [Design Project] System Settings

Mon Jun 16, 2014 10:43 am
Heiko,

Pretend that i didn't use the word 'filter' in the suggestion in my previous post - the function wouldn't be creating a sub-set of displayed items so forget that!

Imagine a casual user who didn't know exactly where every setting is:

1 - They're at the SySe front screen and want to change their screen resolution. They type 'resolution' into the 'Highlight & Search' field (not 'Filter & Search' :)) , press 'enter' and they're presented with a list of results. If they click on the 'Change screen resolution' result then they're taken to the relevant page with the relevant section already expanded and the setting to change the screen resolution highlighted

2 - They've had a go at finding where to change the screen resolution themselves, they've found the right page but it seems like there's loads of settings on there and they're not sure which one changes the screen resolution. They type in 'resolution' and if there's something relevant on the page (maybe hidden away in sections that haven't been expanded) then they're highlighted (or the section is expanded and the setting is highlighted).

I can't really see why you'd want the highlighter to highlight 'yes it's in this top level module - click here' followed by 'yes it's in this level 1 module - click here', then 'yes it's in this section - click here to expand it' and finally a highlight to say 'this is it!'. As long as the search results gave you a clear idea of which module etc you were being taken to (I think Ctown's ideas already do that), i can't see a problem or have i misunderstood what you're saying?

I do still think the 'See also' idea's a good one though!!
User avatar ken300
Registered Member
Posts
314
Karma
0

Re: [Design Project] System Settings

Mon Jun 16, 2014 11:12 am
Heiko,

If SySe was like Anditosan's 'Scrollarea' prototype but didn't have the big icons in the scrollarea for 'Appearance', 'Workspace', 'Networking' etc.. then the navigation through the sidebar would be so fast that i CAN see how the highlight function would mean a search function was of little or no benefit.

But if the large icons in the scrollarea were kept then when a user types in a highlight term, the same top level category would be highlighted in both the scrollarea and the sidebar and that's confusing & would make things more cluttered. Also If the big icons in the scrollarea were kept and the sidebar removed like in the drill-down prototype then IMHumbleO that would make the navigation too slow & cumbersome and the search function WOULD be needed.
User avatar ken300
Registered Member
Posts
314
Karma
0
I'm the first to admit when i'm wrong!

When i said:
i CAN see how the highlight function would mean a search function was of little or no benefit

that's only true if the highlight term that's typed in has only one 'hit', if there's more than one then you'd be left wondering 'do i click on that highlighted link or that other one' so IMO i think that a search function is needed (but still think that maybe the 'search' & 'highlight' functions could be combined into one field to make things simpler).
User avatar anditosan
Registered Member
Posts
152
Karma
0
OS
Hey guys, I tried to polish on that last idea with the top menu bar and give it a spin trying to fit on a 1024x768 resolution. I downsized the type and that gave me a lot of room to work with. One word about KCMs. The organization that you see here is nowhere close to be done. I am thinking that this needs a lot of help in rethinking a KCM from top to bottom. So focus on the bigger idea about the top menu. Thanks :D

Image
User avatar colomar
Registered Member
Posts
943
Karma
2
OS
Navigations which a spread over both horizontal and vertical menus often feel a bit weird to me when using them, but your idea definitely looks very sleek!

 
Reply to topic

Bookmarks



Who is online

Registered users: Ad5001, Baidu [Spider], Bing [Bot], Google [Bot], Graham Perrin, Sogou [Bot], sputnik_tr_02, Yahoo [Bot]