[RFC] (In)Consistency in Isis UX

smz commented 9 years ago

In Isis there is an inconsistency in UX interface: for most components (e.g. com_content) we now have the "Search Tools" above the items lists, but for others (e.g. com_newsfeeds) we still have the "Filter:" in the sidebar. See below:

articles

newsfeeds

Both solutions have their merits, but, IMHO, thanks to the renewed implementation of the sidebar, having the "Search Tools" in the sidebar makes more sense and represent a better usage of the available "real estate". I also find that having the various filtering fields stacked and grouped makes easier to check at first glance what we are searching/filtering for.

I have think to this only in terms of "visual" and UX and I haven't yet looked at the code, but being both the sidebar and the searchtools implemented through layouts, I think it would not be so difficult to to "merge" the two of them.

What do you think?

smz commented 9 years ago

Sorry, but I had to open this issue in GitHub as I was unable to insert images using issues.joomla.org and therefore I've been unable to attach appropriate labels.

richard67 commented 9 years ago

Ah, when I open an issue in the issue tracker, I can attach the labels myself? Can I also chose category there?

Regarding this RFC: I also only judge it by UX aspects, and I would also like to have the search tools in the side bar and not for one thing here and the other thing there, and so I agree.

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5522.}

smz commented 9 years ago

BTW, I noticed that at "phone" display sizes, while the "Toolbar" nicely collapses in an accordion, both the "Search Tools" and the "finder" part of the sidebar just disappear with no apparent way to have them displayed. But this is matter for a separate issue...

smz commented 9 years ago

@richard67 Yes: when you open Issues in issues.joomla.org you can attach labels by yourself. I'm unsure what you mean by "category"....

smz commented 9 years ago

One more aspect (I think I already said that somewhere else, but probably in a now closed PR...):

I see as a great mistake not having "Category" displayed as a sortable column in the items list, even if we have it as a search criterion in the "Search Tools".

richard67 commented 9 years ago

@smz With category I mean the category selection ("ACL", "Administration", "Authentication", ...), just have checked the "New issue" page. I assume it is the same as what you mean with the labels?

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5522.}

brianteeman commented 9 years ago

Personally it would be great if all the components and search tools like com_content. That was always the intention of the UX sprint last year but certain people were against that and made com_content the only one as an "experiment".

As for categories being sortable I "think" the issue was how to handle sub categories

On 25 December 2014 at 18:46, Sergio Manzi notifications@github.com wrote:

One more aspect (I think I already said that somewhere else, but probably in a now closed PR...):

I see as a great mistake not having "Category" displayed as a sortable column in the items list, even tif we have it as a search criterion in the "Search Tools".

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/5522#issuecomment-68110364.

Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. http://brian.teeman.net/

richard67 commented 9 years ago

Well, if it was an experiment with com_content and the side bar, then we now can say this experiment is implemented, and it seems that many testeres liked it (have not seen complaints somewhere), and so we can also say that the experiment has been finished with success, or not?

Could we maybe convince these "certain people" in this way to go on with side bar usage?

smz commented 9 years ago

@richard67 Yes, they are all "labels"

@brianteeman

As for categories being sortable I "think" the issue was how to handle sub categories

Yes, that's the first thing I thought too. What I'll do is to display just the "leaf" (terminal) category name as it is now displayed under the item title, but use the full category tree for sorting.

smz commented 9 years ago

Now, I may be wrong, but wasn't there a time (3.0 or 3.1 maybe) when Category was sortable?

smz commented 9 years ago

@richard67 If I'm getting it right the "certain people" was more on "our side", while Brian is on what has apparently been the "winning party"...

@brianteeman May I ask you for which reasons you find it better to have the search options horizontally aligned (but almost always on more than one line) above the items list?

Wouldn't have them stacked on the left make a better use of an area which is now almost empty (the sidebar doesn't have more than three items anywhere) and will allow more items to be visible especially on wide aspect ratio screens which (unhappily) are the norm today?

richard67 commented 9 years ago

@smz With the "certain people" I referred to those Brian had mentioned. But maybe I got something wrong?

brianteeman commented 9 years ago

For me its about having all the tools in the same place at the top and it is a familiar place for anyone used to using and google products

On 25 December 2014 at 20:00, Sergio Manzi notifications@github.com wrote:

@richard67 https://github.com/richard67 If I'm getting it right the "certain people" was more on "our side", while Brian is on what has apparently been the "winning party"...

@brianteeman https://github.com/brianteeman May I ask you for which reasons you find it better to have the search options horizontally aligned (but almost always on more than one line) above the items list?

Wouldn't have them stacked on the left make a better use of an area which is now almost empty (the sidebar doesn't have more than three items anywhere) and will allow more items to be visible especially on wide aspect ratio screens which (unhappily) are the norm today?

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/5522#issuecomment-68111732.

Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. http://brian.teeman.net/

richard67 commented 9 years ago

Regarding stacked on the left or not: We maybe should check on mobile displays, too.

smz commented 9 years ago

... I think so, but maybe I got it wrong... :smile:

smz commented 9 years ago

On phones the stacked search options should become an "accordion" between the "Toolbar" and the "Items"...

richard67 commented 9 years ago

Ah, I see.

brianteeman commented 9 years ago

Do you really need to be able to do everythign on a phone? Personally I only ever do minor emergency tasks on my phone.

On 25 December 2014 at 20:05, Sergio Manzi notifications@github.com wrote:

On phones the stacked search options should become an "accordion" between the "Toolbar" and the "Items"...

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/5522#issuecomment-68111836.

Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. http://brian.teeman.net/

richard67 commented 9 years ago

No, I even do not have a smart phone. But maybe some people admin their websites with it? I don't know.

smz commented 9 years ago

Do you really need to be able to do everythign on a phone?

I never manage my sites from my phone, but it seems to be the craze of the moment... "mobile first"!

Bakual commented 9 years ago

That doesn't need an RFC. Just create a PR to introduce search tools for other extensions. It just happend thast nobody wrote it so far.

smz commented 9 years ago

@Bakual Thomas, the point here the UI/UX for "Search Tools": I (and @richard67) would like to move them to the sidebar. I can try and create a PR for that, but I wouldn't want to waste my time in case decisions are already taken and immutable about their positioning...

Hackwar commented 9 years ago

I have to say that I don't like the search tools at the top horizontally. I had the experience myself and with 3 clients that we all couldn't find the filters in com_content and after we all found them (or rather my clients were directed by me) we all said that it was inconvenient that you have to do that one more click to even display the available filters...

Hackwar commented 9 years ago

Oh, and as @Bakual said earlier, it would be better to bring stuff like this up on the mailinglist than in an issue like here on github.

richard67 commented 9 years ago

Well if Search Tools everywhere and not side bar, then is also would be consistent. Better than nothing from my point fo view. But as @smz does, I think, too, that some decision would be necessary about which way to go.

smz commented 9 years ago

Oh, and as @Bakual said earlier, it would be better to bring stuff like this up on the mailinglist than in an issue like here on github.

Well... it doesn't seems to be what @Bakual said, but, yes, I agree that the mailing list too can be a "place" where to ask opinions about this. I did here mainly for two reasons: 1) I started writing this as an "issue" (the inconsistency in the UX between different components), but then changed my mind and constructed it as a question about which of the two is preferable, and, 2) as this seems to be a matter that at the end will require a PLT decision, I considered this to be the place where to get "closer" to the PLT as a whole that I have access to.

What to do now? Maybe I can post to the mailing list a link to this...

chrisdavenport commented 9 years ago

I'd like to see some UX testing being carried out to determine the best course of action.

My personal preference would go for putting the filters in the sidebar, but that counts for nothing without real evidence that it works better for real users.

Bakual commented 9 years ago

Personally I like the Search Tools better than the sidebar. Both as a user and a developer. It's also the direction chosen for the CMS and the idea always was to do the other extensions as well. Like said already.

So unless you have strong arguments why th sidebar is better, I wouldn't waste the time to revert the Search Tools implemented in com_content. By the way: If you look at their search UI, Google also seems to think that a button to show advanced filtering/sorting is fine :)

Bakual commented 9 years ago

But please take such discussions to the mailing list. GitHub really isn't well suited for that.

cyrezdev commented 9 years ago

By the way: If you look at their search UI, Google also seems to think that a button to show advanced filtering/sorting is fine :)

Yes, it's working fine for Google, but google is a search engine, and the "search tools" feature is integrated in the "submenu" of the search as an element of this menu (Web, Images...). ;-)

BUT, where should we go to discuss of this now (yes better to have discussion in the right place)? Here : https://groups.google.com/forum/#!msg/joomla-dev-cms/_LeCJN4Duck/OzcNQZPu9NYJ ?

Or by creating a new topic ?

Note that i'm a volunteer to work on consistency of the Search tools, as well as to make it available with a button on mobile device ;-)

Cyril

Post Scriptum : @brianteeman i was 2 months this summer lying on a bed after a hospitalization, and search tools could be useful on mobile ;-)

Bakual commented 9 years ago

The thread you created is fine imho.

smz commented 9 years ago

@Bakual I don't know why you don't like RFCs here (and sorry, I missed that before opening the issue: I saw your comment in Brian's RFC only later on).

IMHO, compared to the mailing list, here we have a much more orderly organization, we don't have "citations over citation" (excluding some rare exceptions), an history is kept and in a way it becomes a more "official" document, stored on our servers too (the J!Tracker application). Inserting code snippets and screenshots is also way easier here.

I understand that we have quite many issues open, but we could introduce a specific tag for RFCs/discussions to filter them out when doing a "sanity check" about "what do we have still pending".

The optimum would be an area outside the "issues" for RFCs and, who knows, maybe even a polling app to tally how many are pro/against a specific proposal. In the mailing list there is too much clutter to do something like that...

Wouldn't this be a way to promote "The Joomla! way" (in the original sense of the word)?

Of course you're the boss and I'll abide, but... think it over...

Bakual commented 9 years ago

This is an issue tracker. It's not a discussion forum. We currently have over 100 open issues and almost 400 open PRs. We really don't need additional issues opened just for discussion. Also, in GitHub you get notifications for every updated issue. Depeneding on the settings you also get an email for it. On a busy day, that's over 100 notifications for me. I don't like additional notifications coming from discussions.

Last but not least, we already have a perfectly fine platform for discussions. Let's use it.

The optimum would be an area outside the "issues" for RFCs and, who knows, maybe even a polling app to tally how many are pro/against a specific proposal. In the mailing list there is too much clutter to do something like that...

Please, just not another place to check. We already have more than enough applications and channels where something happens.

Of course you're the boss and I'll abide, but... think it over...

I'm not the boss. I just try to keep my (and our) sanity here :smile:

smz commented 9 years ago

Really, really, really don't take this as a blunt reaction, but:

to some this is an issue
notifications for a specific issue can be turned off
what you see as a "perfectly fine platform", IMHO sucks big
I agree that "one more place" has its big disadvantages
you're not the boss but you rule on what is fine or not to do here... :stuck_out_tongue_winking_eye:

Bakual commented 9 years ago

Actually, the project is run by the contributors. If all of you guys want to use GitHub for discussions, then so be it.

mbabker commented 9 years ago

IMO you use what works best for a project. In the case of the issue tracker, we have all but abandoned every platform we've tried that isn't GitHub; it just works for us. Maybe it works here for code talk, maybe not. Nobody knows for sure.

On Friday, December 26, 2014, Thomas Hunziker notifications@github.com wrote:

Actually, the project is run by the contributors. If all of you guys want to use GitHub for discussions, then so be it.

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/5522#issuecomment-68157919.

smz commented 9 years ago

I would like to recap which are the issues I see in the current user interface. The role of the sidebar will be pivotal in my analysis, but I'll also digress:

The role of the sidebar:

The sidebar should be a pivotal element of the user interface and host a multitude of elements, utilizing an otherwise unused screen area.
As it is now it is greatly underused, hosting what is essentially the list of possible different views for the active component. The empty area under it is wasted.
Correctly implemented it will show its usefulness in "mobile" screen sizes.
At this time it is instead hidden (has class hidden-phone) in "mobile" screen sizes
A correct implementation will be that it becomes an "accordion" element located between the "Toolbar" accordion and the items list

What in my opinion could be a perfect implementation:

The sidebar should contain all that is not "Items list", and the right area should contain just the items list
When I say "all" I mean just that, all: "Search Tools", "Menu selection" (in com_menu), "Sorting options", "Pagination limits", everything.
Unrelated elements should be separated by a thin horizontal line and have a little more spacing.
Group of related elements should be grouped and possibly have a group header
The "Search" (input box) and "Filter" functions should be kept separate, with separate "clear" buttons: I don't want the "Clear" for the "Search" input box to clear my filters too!
"Search" input box and its "Clear" button should be on the same line and an "x" icon is enough for the "Clear" button
A filter for "Featured" attribute should be implemented (and the "Featured Articles" view eliminated from the sidebar)
"Categories" and "Level" should be on the same line. A short heading for "Levels" is enough.
Group of options should be organized from top to bottom according to their relevance in the context: most used or hierarchically more important at the top, less used at the bottom
On the right side, for items list, the header for columns could be sticky to the top (at desktop sizes)

Unrelated:

"Database" and "Warnings" do not belongs to "Extension manager" (even if they do programmatically): they should go to the "Control Panel" (Warnings)" and to "System" (Database)
"Joomla! Update" should be in the sidebar of "Extension Manager"

Hackwar commented 9 years ago

Hi Sergio, while I agree with a bunch of your suggestions, I feel that this issue already goes massively offtopic. It started with the question of the hidden top filters vs. having them at the sidebar and now we are moving into totally different territory with refactoring search and filtering etc. I would split this up into 6 issues already.

How to make writing filters smarter. Because right now we can't simply change the position of the filters in the template.
Where should which part of the UI go? I personally want the pagination and page limit to stay where they are.
How should some of the elements on a page be formatted?
How can this also be done in the frontend?
How best to re-organize com_installer? See #5283 for a start
Do we need a system-health view somewhere and what should that contain?

That said, I would call it an initiative (for example "UI Changes 1/2015") and then have a discussion on the mailinglist for each of these, open one issue that keeps track of all issues/PRs related to this initiative.

Now, you want to have the maximum visibility for this in the beginning and that means the mailinglist. The issue tracker is NOT something that everybody visits all the time.

I'm happy to help you with all of this, but I'm a bit busy until the next year. If you want, we can discuss that then, even via Skype, and see how we can proceed. :smile:

Bakual commented 9 years ago

How can this also be done in the frontend?

Btw: Search Tools as done in com_content works also fine in frontend. I implemented it with my extension and it works even with less code than I currently have.

Bakual commented 9 years ago

There is also the UX forum: https://ux.joomla.org/ It was active around the time those UX changes were done. Today it's quite inactive. If we need a place to discuss UX things, that could be a place to relive if someone is interested.

coder4life commented 9 years ago

This was the original thread that started the logic about the com_content decision.

https://ux.joomla.org/forum/Usability/1062-improvements-ui

Personally I still feel the approach we have now is still flawed, and from experience what I have in that post has been working so far with little to no existing support requests.

smz commented 9 years ago

@coder4life Josh, thanks for the link. Essentially what I see is several proposals, the last one being Beat's one which roughly correspond to what we have now, and no decision by consensus...

I like what you proposed (dropdown filters above columns), but how do you cope with situations where more choices must be made about a "field", like with "categories", where you have to choose the category and the level? Side-by-side? That kind of interface would make particularly sense if it would be possible to choose which columns to visualize and leave more room for the "interesting" ones. In my day-by-day operation, as an example, I have little to none use for the "Author" field, but I'm sure there are other situations in which that information is of paramount importance and (always as an example) "Access" is of zero interest.

Once again, anyway, I think current implementation in com_content (filters above + sidebar on the left) is the less intuitive, makes yours eyes jumps like crazy, fatigue and loose focus.

smz commented 9 years ago

... and I still consider not having "Category" as a column is very close to a mortal sin.

coder4life commented 9 years ago

@smz Yeah, this is why we did it the way in the screenshots listed in that thread in all honest. The goal was to avoid jumping between the sidebar and the table and not understanding the direct association with the filters with the data in a more immediate way. In the current design in Joomla (not in com_content), there is a process of "searching/finding" how the filter is labeled and how the table column is labeled to learn correlation between the two sets of items that do actually interact in a way. With lots of data this requires a lot of "eye-scan". We wanted to avoid the jumping scenario. The filters in the picture on that page were based on a concept of preemptive thinking, and why they exist at the top of the table and give meaning to what was being filtered below. There is also a scenario where the screen real-estate is smaller and the filter list would be pushed down by sidebar menu items or many listed filter functions, which makes the jumping scenario worse. This was our best test case.

There is one thing we failed to address though, too many columns. Filters that work on the same column could be stacked, or wrapped in some form (not pretty but in large screens you will not notice this). One way to solve this is for multiple filters per column have some sort of modal (on mobile phone a full screen view) that would bring up a more sophisticated input mechanism. As for the column situation, some items really do not need filters, or could share a filter, especially were data will take two lines in one row.

However I still feel the implementation in "com_content" missed the mark. Not sure if it is better or worse, but from a UX perspective I did have some issues using it frequently until I remembered about the change and clicked the button to open the filter list. However, the thing I came across in experience, its just a list of filters I have to scan through to find what I actually need, and that inherently is a user experience problem with the current design choice in "com_content".

(NOTE: Those screenshots in that thread by me (coder4life) are from Kunena and are not in Joomla, just for clarity)

coder4life commented 9 years ago

In all honestly I rather have the sidebar a category list with a clicable menu, because by desgin that is what categories I meant to do. In the case of sub-categories on mobile views we could just have a list view (which is a common design decision on mobile phones) and drill down to specific items on a mobile interface (on desktop interface we could keep it as a sidebar). That would go to great lengths to clean up the current design of categories, child categories, and child items.

tottello commented 9 years ago

Everything on left is better, because now you can hide sidebar - (before that 'search tools' was ok)

Sidebar should have other icon imho, because 'x' icon is more for closing for good.

IMHO word 'select' in every select tag is not necessary. I always have to read more to find what I'm looking for.

sidebar

richard67 commented 9 years ago

@tottello If the sorting section of the side bar would be labelled with "Order by:", as the filtering section is with "Filter by:", and it would also have a button to hide it at its top right corner, as the other 2 sections above have, then the side bar shown on the screenshot above would be closer to perfect ;-)

@all The above screenshot

my suggestions @tottello
rename of "Featured" button to "Feauture" and adding of "Unfeature" button as comitted with recent PRs
a new button for "Unarchive"
a new list view "Archived Articles" as we have for "Featured Articles"
consistent ordering e.g. of sort and filter options and displayed columns in the Articles, Feautred Articles and Archived Articles lists => Perfect in my opionion.
_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5522.}

tottello commented 9 years ago

I updated the view. Another suggestion is to change color for current menu item on left. (for me current - long blue - version is little bit too much eye catching. Two versions of current item background: white and gray. sidebar_gray sidebar_white

brianteeman commented 9 years ago

Personally I really dont like this removal of the search tools back to the side from above the content where to me it is more logical

On 12 January 2015 at 23:32, tottello notifications@github.com wrote:

I updated the view. Another suggestion is to change color for current menu item on left. (for me current - long blue - version is little bit too much eye catching. Two versions of current item background: white and gray. [image: sidebar_gray] https://cloud.githubusercontent.com/assets/8938743/5713235/41d2c22a-9aba-11e4-9d34-72d0c170f498.jpg [image: sidebar_white] https://cloud.githubusercontent.com/assets/8938743/5713339/4bf69078-9abb-11e4-912b-3b13651b54fb.jpg

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/5522#issuecomment-69668358.

Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. http://brian.teeman.net/

tottello commented 9 years ago

Still something should be done in other components

joomla / joomla-cms