Adrian Schröter - 18:25 10.01.14 wrote:

On Freitag, 10. Januar 2014, 16:33:00 wrote Michal Hrusecky:

...

Hi,

I have been playing with OBS recently and one of the things I was trying to achieve was to improve UI for reviewing requests. I have my OBS instance running & patched although I took a few shortcuts, so to have a real submitable patch ready (not speaking about test I have no clue how to write), there is still a long way to go. But before I put more effort into it, I wanted some check whether these changes actually makes sense and would be welcomed or discuss them in general. Attaching screenshots as machine I have this running on is accessible only internally.

Changes summary:

Overall the idea was to simplify the request webpage and get inspired by github. Get rid of too many elemnts and move stuff to tabs.

* request history, build results, rpmlint results and issues are tabbed together with diff * comments and request history merged * show by default request history (intention is to be more clever in the end - ** show diff if there is only creation in history, show history if there are reviews, comments and more...) * all actions in one tabbed window - review, decision, comment creation * cookie based seen/unseen for comments/request ** not really perfect, but helps to notice what changed since the last time * since request history is in big window, expand all comments so people can easily read all the info

What do you think? What do you like? What do you dislike? Shoot!

I have not final opinion, but just to give you some feedback.

The current page is still quite confusing and far away from optimal from my POV. Yes, not your fault :)

However, I would like to brainstorm a bit where we want to go in the end. In my opinion we could improve this page a lot by various more logic which helps to find the important pieces.

That means keep the buttons to show everything, but highlight to most important items to decide.

For example: * When the package does not build anymore in a repo, which is relevant for the target, have a "big red warning".

Nice idea, if I dig deep enough into buildresults code, I can probably come up with something to put into notice.

* Improve the diffing view. If it is a new package, it does not make sense to show entire changes file and all mentioned bug issues. IMHO it would be more important to show a package description to understand why to the target should add this package at all.

Well, I agree that changes is probably not the most important file in the new package, but the spec is... So this would need disto/packaging specific hacks to do some reordering (as you might want to check changes as well even in new package) and I don't like the idea of making webui behave differently for every distribution...

* Results from source validators and also rpmlint output should get filtered as well to highlight new breakages esp. (maybe something for the QA track).

So far I was playing with showing history tab by default if there is more than two changes (review?) or at least one comment and show diff otherwise. That is quite easy. As build results go, I didn't dug deep enough to put them into equation. They can also be refreshed apart from the rest of the web, so after refreshing them, what is important might change (in both ways). Did you have some other more clever/prettier way of highlighting in mind?

In general I dislike the history look. This is maybe just a matter of CSS, but to be fair, I can not tell either how it should look :/

hmmm, I pretty much kept the current one as I was quite Ok with that (except of it's size and position and collapsing important info). What about instead of request changed/comment added using some simple icons? Or do you dislike the table view in general?

In the decision box at the button one has to decide first what kind of action you want to do (via tab bar) and then selecting the action. IMHO this could be merged and presented more logicaly. github.com is quite understandable here, by having just buttons below the comment field like:

"Comment" "Review accept" "Review Decline" "Request accept" ...

Yes, that would be quite a lot buttons, but keep in mind that usually only a subset are visible, because the user has only a specific role in the request.

Agree with that but as that would require quite deeper cuts I left it for more distant future, after discussion of initial and quite easy to do changes :-)

Again, I know that the page has the problems also before you came. I do not want to blame you, it is great that you work on it. But I think we need to aim not far enough yet.

Ok, let's brainstorm :-) -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org