Adrian Schröter - 18:25 10.01.14 wrote:
On Freitag, 10. Januar 2014, 16:33:00 wrote Michal
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.
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.
* 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
* 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
understandable here, by having just buttons below the comment field like:
"Comment" "Review accept" "Review Decline" "Request
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
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org