Design "global issues view"

[calexity]

Design view for https://github.com/webcompat/web-bugs/issues?state=open

[calexity]

@miketaylr @magsout @karlcow

Couple half baked ideas on Browse All Issues

Browse by triage state

Browse in order by date with optional "Bugs I'm working on"
(if it's possible to pull this info in based on an assignee)

[miketaylr]

Yay! I think we need a search widget/box up at the top as well as way to set up filters (label, assignee, whatever).

Github's is pretty cool, thought I'm not sure I did the complicated search syntax stuff.

I like the look and feel of what you've designed--it's got a cool "dashboard"-like vibe to it. I wonder if we might explore displaying all issues as a single column like GitHub does. That approach makes it easier to filter/sort everything at once I think.

[calexity]

Great points @miketaylr. Thank you for the feedback.

A couple questions -
What do you mean by "I'm not sure I did the complicated search syntax stuff"?

Also for everyone - Github has a ton of filters, sort and search abilities. Leaving out PRs, I found at least these below. Which filters/sort are most important for the Webcompat community?

• Filtering by open/closed
• Filtering by "Your Issues"
• Filtering by Everything assigned to you
• Filtering by Everything mentioning you
• Filtering by Stage (Untriaged, Needs Diagnosis, etc)
• Filtering by Label (Firefox, IE, etc)
• Filtering by Author
• Filtering by Assignee
• Sort by Newest
• Sort by Oldest
• Sort by Most Commented
• Sort by Least Commented
• Sort by Recently updated
• Sort by Least recently updated
• Search by keyword

New undercooked design below

• The "View all open issues" would be a filter that could operate like the one in Github (all open issues, your issues, assigned to you, mentioning you)
• Untriaged, Needs Diagnosis could all be filters that turn on and off on click
• Search - @miketaylr need some guidance here on how big to make this and what capabilities it could have - does it need to work with search syntax like Github does?
• Newest is a drop down to sort by date
• Possibly the labels (firefox, ie, etc) could be used to sort on click
  

[miketaylr]

What do you mean by "I'm not sure I did the complicated search syntax stuff"?

Just a terrible typo. :/ s/did/dig/. typing is:open, etc. See https://help.github.com/articles/searching-issues for more examples. Possibly something to incorporate at a later point, but I think we should start simple.

[miketaylr]

Search - @miketaylr need some guidance here on how big to make this and what capabilities it could have - does it need to work with search syntax like Github does?

As far as capabilities go, we can choose. It could be anything as simple as plain text search over all issues to the advanced github search syntax. That's all supported by the Search API: https://developer.github.com/v3/search/. It can actually be both at once as well.

I might be talking myself out of my earlier comment.

Possibly the labels (firefox, ie, etc) could be used to sort on click

+1. I imagine clicking "firefox" would populate the search box with label: firefox.

[miketaylr]

Which filters/sort are most important for the Webcompat community?

I'm curious to hear @karlcow's opinion on this. For me, probably all the options listed are useful, depending on what I'm trying to do (probably less so for Assignee--but if we expose that in the issue someone could click that and we could kick off a filter of that).

[magsout]

@calexity

Maybe two issues per lines ?

Untriaged, Needs Diagnosis could all be filters that turn on and off on click

Maybe add background-color instead of border-color and add on top/right corner an icon (plus and minus) ?

Add a new select box to selecte the number of issues par pages ?

Very good job @calexity, like it.

[karlcow]

Which filters/sort are most important for the Webcompat community?
I'm curious to hear @karlcow's opinion on this.

Plugging brain. bzzzt. reading again the full thread. 🕐 🕑 🕒 sound of 🚜 up there.

ok. Let's see. Maybe a way to think about it is to ignore what github proposes and think what I would like to see there. Then see if it's doable with github tools as they are. I can imagine two states:

• I'm Susan. A regular contributor (logged in user) coming for tackling new work since the last time I came.

• I'm Paul, a newcomer (non logged), I have read an article about this Web site and wanted to discover.

• I'm Aminata, a journalist (non logged), and I come often to search things about companies with bugs.

• I'm Ahmed, a Web developer (non logged), and I come often because I know I can find good materials for solving issues about Webcompat.

  What is expected from these users is different in needs and actions. @miketaylr said start simple. 👍

I'm thinking about the non logged users now and below.

So indeed this top dashboard. Want to be clickable.
Beside each label (maybe in the box view), I think there might be a need for count information. [Note to @miketaylr I wonder if we will get into troubles when there is thousand of issues. size of the JSON file].

I might want to be able to search by domain name. I might be a reverse domain search to make it easier (to think). Basically, if I'm coming for the first time, I might want to know if someone has already reported my bug for this site. Typing the domain name could bring all the issues related to that domain. Where it will be wholly not effective is that in our current dependency of github. The domain name is in the body, which means there is no search feature from github for it. Though we could create indexes on webcompat side. We can parse the current bugs and all new bugs could feed the DB creating an index.

so someone typing google.com would get all bugs related to google.com

Other information we have: number of comments, last updated date. I wonder if there is a karma that could be computed for each bugs: Pampered (already a lot of activity)/ Need Love (not that much activity for a long time). This to encourage people to help with old bugs.

I will keep this running in my mind for the week-end. Maybe there are more type of users we haven't thought about and that could influence the design.

For logged in users. I have the feeling the page should be entirely different but that's for version-n++++

[karlcow]

BTW, I was just wondering if we are talking about sorting (order in which things come) or about filtering (reducing the set of things which are visible)?

Also an idea which just popped up in my silly mind. @calexity Do you know the "Developer Toolbar" in Tools -> Web Developer in Firefox.

It's a very interesting system based on command on a combination of typing ahead, commands and suggestive placeholders. It's really well done in terms of UX.

Now let's say the user put the cursor in the search bar: what could happen for guidance?

Imagine for example something like… Here I will use paranthesis to express gray.

[r(eport)                          ]
TAB
[report (domain)              ] (or whatever options we consider good)
[report google.com ]
Enter -> prefilled bug report

[s(earch) ]
TAB
[search  s(tatus:) ]
TAB
[search status:o(pen) ]

[miketaylr]

[Note to @miketaylr I wonder if we will get into troubles when there is thousand of issues. size of the JSON file].

Good point. We can ask the API for issues to be paginated, rather than display everything at once.

The domain name is in the body, which means there is no search feature from github for it.

Nah, you can do a plain text search over issues. See https://developer.github.com/v3/search/#issue-search-example and https://github.com/webcompat/web-bugs/search?q=google.com&type=Issues&utf8=%E2%9C%93.

[calexity]

Hey @karlcow @magsout @miketaylr et al - I moved the screenshot to Invision so it's easier to comment on pieces of the design. Can everyone see and comment on this?

I added questions there. I can actually link together a small prototype of how it might work and we can punt it out on Twitter and the mailing list for feedback.

https://projects.invisionapp.com/share/EC1E27VFU#/screens/38185232/comments

[calexity]

Here's an example of what Susan (@karlcow's persona) might do when she lands on this page:
http://invis.io/A31E2GRVY

Prototype will move on it's own right now.

[calexity]

Thank you all for the feedback @magsout @miketaylr @karlcow

I made some changes on Invision (you can toggle comments on/off on bottom right of screen)
https://projects.invisionapp.com/share/EC1E27VFU#/screens/38185232/comments

I also walked through some of Karl's use cases. Those were extremely helpful. Karl - am I missing key activities?

I turned off auto forward, just page through using right arrow
Susan, the regular contributor
https://projects.invisionapp.com/share/A31E2GRVY#/screens/38191966?maintainScrollPosition=false

Paul, the newcomer scoping out webcompat
https://projects.invisionapp.com/share/A31E2GRVY#/screens/38537262?maintainScrollPosition=false

Aminata, the journalist looking for a specific site
https://projects.invisionapp.com/share/A31E2GRVY#/screens/38537443?maintainScrollPosition=false

Ahmed, the web dev looking for help with web compatibility
(in this one, he clicks the "Firefox" label and the search bar populates)
https://projects.invisionapp.com/share/A31E2GRVY#/screens/38537649?maintainScrollPosition=false

Should we tweet or send this out for comments by the community? Is it easy to understand?

[magsout]

@calexity @miketaylr
If a persone selects all issues: pagniation or all on one page?

Should we tweet or send this out for comments by the community? Is it easy to understand?

Uses case are easy to understand. Very good job @calexity

[calexity]

I am missing the pagination! Thanks @magsout I think it's too much to
render on one page.

I will add it on the top right.
On Sep 21, 2014 1:50 AM, "Guillaume Demesy" [email protected]
wrote:

@calexity https://github.com/calexity @miketaylr
https://github.com/miketaylr
If a persone selects all issues: pagniation or all on one page?

—
Reply to this email directly or view it on GitHub
#169 (comment)
.

[karlcow]

@calexity wonderful!

This is good stuff, and good materials to help us understand.
Not all features have to be developed right away but can guide us when developing the simple stuff (thinking "Oh here there will be something possible").

Nice! I wonder if we should ask to the people who helped us on bugs in the past what they think about this tool and it would improve (or not) their own work.

About tweeting. Yup.

[magsout]

Sent first version.

Tell me what do you think @karlcow @miketaylr @calexity @tagawa

Dropdown need JS to work. Add .opento <div class="Dropdown open>

Some dropdown are different than mockup of @calexity (show number per page and big dropdown).

Filters are below the big dropdown because there is still not enough space

Open to any feedback you all have.

[miketaylr]

@magsout this looks great right now. :D

I'll start working on #266 on Monday. I think we'll get a better feel for how it all works as we start something up and running. As an FYI I changed the route to /issues rather than /issue-list.

[calexity]

@magsout I see your commits, but I can't load the app on my local computer, so I can't see the page yet.

I wrote responses to your Invision comments which I hope are helpful...I think we'll have some work to do to optimize this for smaller devices. We might think about an option collapsing the sort/filters to optimize for issue browsing. I'll consider how this might work and post something soon.

[karlcow]

@calexity Do you need a manual or a step by step to get the right version of @magsout
I just noticed in the Contributing, it is not explained how to install a specific branch for testing.

[calexity]

@karlcow no, the documentation is pretty thorough. I'm just inept with computers. I think it's fine if you can all see it. Once it goes to staging, I'll look at it.

[magsout]

@calexity

I wrote responses to your Invision comments which I hope are helpful...

Thanks , fixed and sent.

I think we'll have some work to do to optimize this for smaller devices. We might think about an option collapsing the sort/filters to optimize for issue browsing.

yes, agree.

[tagawa]

Looking really good @magsout. A couple of minor comments:

• Perhaps we could try having the status buttons (Untriaged, Needs Diagnosis, etc.) with a slight arrow shape, e.g. a triangle shape on the left/right to show the flow of the stages.
• This is a naming issue rather than design, but I think "untriaged" may be difficult to understand for some non-native English speakers. I wonder if there's an easier alternative, such as "new". This could also clarify the difference between "untriaged" and "needs diagnosis". (But this is probably the wrong thread...)

[magsout]

thanks @tagawa

Perhaps we could try having the status buttons (Untriaged, Needs Diagnosis, etc.) with a slight arrow shape, e.g. a triangle shape on the left/right to show the flow of the stages.

When status button is-active, there is background-color puts on Button like :hover state. Need more, do you think ?

[tagawa]

I was thinking more this kind of shape (ignore the colours/text), possibly with a slight space between each button:
http://www.freepsddaily.com/wp-content/uploads/2011/07/steps-panel01_main.jpg

[calexity]

I think using "New" instead of "Untriaged" is a great idea.

Re: the arrows, I worry that that pattern doesn't signify that it's clickable. Maybe if we leave them disconnected, but just the right side is an arrow it will be fine, which is what I think you are suggesting @tagawa

[tagawa]

Yes, sounds good @calexity, although I'm not pushing hard for this - it was just a thought.

[miketaylr]

Good idea. I filed #286 to track that. We should hold off for a few days before we try that as I'm hacking up the Backbone files trying to make them more reusable.

[miketaylr]

I've deployed what I've done so far to http://staging.webcompat.com/issues. Note that "team" is hard-coded for now. I need to think how to easily pull that in, I guess issue filer + comment author (minus @webcompat-bot?). This might be something I come back to after doing everything else.

I know we're not to the polish phase yet, but the composition looks a little unbalanced. How do we feel about pulling in label bg colors?

[tagawa]

It looks OK. I think I know what you mean about being unbalanced. Maybe a tiny tweak like rounded corners on the right-hand side only could balance the coloured line on the left?

For "label bg colors", do you mean the label text should be coloured? I think so but some of them may lack contrast. Another option is coloured text-shadow, or coloured underline, etc.

Speaking of contrast, the "Search by keyword" seems much paler than in the design preview and not good for accessibility (or bright sunlight). Maybe we should think about whether we have a minimum contrast across the site to comply with a certain level of WCAG, or if we don't worry about that at this stage.

[calexity]

Agreed about the unbalance.

I notice a couple things we could fix to help this -

1. make the issues 2 lines where the labels sit on one of the lines (probably the bottom)
2. make the issues left align so they sit next to the other text (as they do in Github)
3. make the issues max size smaller so they are not so large
4. possibly use a sidebar with the free space, though I think that's more visually overwhelming

I tried a couple ideas (below). I'm not sold on them and am open to other ideas.

I think @tagawa's idea to use color text in the labels could be cool. We might have to choose a palette there so they are readable.

Daniel - re: contrast - do you mean the contrast of the field color vs adjacent colors or the contrast of the text vs field color is low? I tried a few different ways to render that search box, but couldn't find anything I thought worked better. I think we can easily make that text darker if that will help. Also, do you have any experience with accessibility testing? I'd love to do that for this project.

[magsout]

@calexity I like first screenshot.

@calexity @miketaylr @tagawa

I thought about small device like smartphone or phablet.

I thought something like, see only the search bar and issue . The user would have to click on filter button to display the filters (select box and sate issue).

[calexity]

@magsout that makes a lot of sense to me. I think we'll have to use a different background color (to distinguish from the top nav bar). I had done this design before, which I can't find in this thread. My only concern is putting too many filters in one dropdown.

[magsout]

@calexity

I think we'll have to use a different background color (to distinguish from the top nav bar

Agreed

I had done this design before, which I can't find in this thread. My only concern is putting too many filters in one dropdown.

and in fact http://staging.webcompat.com/issues is done like you screenshot.

This idea all together in a button will add elements later and especially space-saving high on small screens.

[miketaylr]

Did we ever come up with a design for pagination? I think I'd like to deploy this feature in smaller chunks--if we have a frontend for pagination then we could release an issues page with all the filter buttons (and then incrementally add the sorting, search, etc.)

[calexity]

@miketaylr

Simple version just adding pagination to what we have

Couple other versions that may or may not be better. I'd love to get the pagination on the top because I think it's easier to navigate from top but I'm having trouble making that work.

cc @magsout @tagawa

[tagawa]

"simplest" version gets my vote because a) pagination on top aligned with "Show 25" and "Newest", and b) easiest (and therefore fastest) to implement.

The others look good too if we could make it nicely responsive for wide screens.

[karlcow]

like @tagawa I would target the simplest possible. We haven't released anything outside of staging on the main site. I'm a bit worried that it will bite us at a point. Basically small increments, rinse and repeat would help us to learn. Specifically at this stage where the number of users is small. Deploy more often, fail fast, improve. Too many things are blocked in the pipe which are not related to the design.

[miketaylr]

Too many things are blocked in the pipe which are not related to the design.

Which things are blocked specifically? We have one changeset related to caching, which is good for us because it saves us on API requests. But not really a user-facing feature. And we have a few changesets related to documentation.

The whole point of asking for a design on pagination is precisely so we can release a smaller increment:

I think I'd like to deploy this feature in smaller chunks--if we have a frontend for pagination then we could release an issues page with all the filter buttons

Patches welcome. :)

[miketaylr]

@calexity I like the first "simplest" version--it looks nice. @magsout can you help add that to the dev branch?

[miketaylr]

Just wanted to add that the 2nd design looks like an awesome tablet-experience layout. Something to revisit maybe.

[magsout]

@miketaylr add pagination

[magsout]

@miketaylr @calexity

Just wanted to add that the 2nd design looks like an awesome tablet-experience layout. Something to revisit maybe.

We can use it for tablet-experience, and keep actual design for wide device. Just thinking about small device

[karlcow]

@miketaylr said:

Which things are blocked specifically? We have one changeset related to caching, which is good for us because it saves us on API requests. But not really a user-facing feature. And we have a few changesets related to documentation.

Yes my point. not related to the design. ^_^ needs discussions but elsewhere.

[magsout]

Maybe we can close that looong issue ? And re open another for tablet/mobile-experience ?

[miketaylr]

👍

But up to @calexity, I think.

[karlcow]

Yes that sounds a very good idea @magsout And we can interlink them anyway.

[calexity]

Sure thing - done. #349