Am Friday, 24. June 2011, 11:58:33 schrieb Justine
I'm working on improving the project / package views in OBS mobile.
There are a few changes I'd like to propose and discuss. It would be
great to find out if they would help make OBS mobile more efficient and
powerful to the mobile client users before final implementation.
Discussion is also posted on my blog:
1. Add “Project Status” on the project view page to indicate the
overall real-time status of this project, possibly categorized as
- Stable: project is ready for end-users to use.
- Testing: project should work from a developer’s point of view, but
needs more testing.
- Development: project is in a random state; it might work.
- Private: project is not intended for public use.
Makes absolut sense. however we should do so in all front-ends in then and
store the data in api.
It seems you found the fate entry already :)
I can add such an attribute with these 4 allowed values to OBS code base,
so that every frontend can use it.
Is OBS:QualityCategory a good attribute name ?
Please, not another attribute. This really belongs into the 'Project' model,
thus we should store this in the project meta instead, probably as an
2. Organize the package view page like this:
Description tab would be removed from this page to reduce redundancy,
since it already appears on previous few pages.
Files, Requests, and Failures would be changed to collapsible view, and
have a count in the header to show the latest status, so that the user
doesn’t have to tap open each button: http://susepaste.org/39817759
Looks good, but it would maybe make sense to offer direct links to the 2
open requests here. There is not much new information in the text below
A tab called Notes would be added to this page to
show some other
packages (the links will go to the corresponding package view pages) in
the commit history that might trigger a rebuild of the current package.
It might look something like this: http://susepaste.org/5804598
Hm, I am unsure if the really makes sense. The result can be very large.
I am unsure if a mobile user really wants this, when the classic webui
user has not even asked for this yet .....
3. About these buttons: are they better bearing
collapsible views or
sliding over to related screens?
For example, here's the sliding view of Repositories:
vs. collapsible view:
I think the later one gives more space on the screen and reduces the amount
of loaded data (important for the mobile view IMHO).
> Of course, we still need to convert those html webpage views to mobile
> So, what do you think of these changes? How could I make it better? Any
> comments and suggestions would be greatly appreciated!
> Thanks in advance,
> Justine Leng