[opensuse-buildservice] OBS mobile: project / package view changes
Hi all, 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: http://obsforandroid.wordpress.com/2011/06/10/obs-mobile-package-page-makeov... 1. Add “Project Status” on the project view page to indicate the overall real-time status of this project, possibly categorized as follows: - 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. Screenshot: http://susepaste.org/33683563 2. Organize the package view page like this: http://susepaste.org/45272178 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 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 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: http://susepaste.org/45395077 vs. collapsible view: http://susepaste.org/26703741 Of course, we still need to convert those html webpage views to mobile views. 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 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Friday, 24. June 2011, 11:58:33 schrieb Justine Leng:
Hi all,
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: http://obsforandroid.wordpress.com/2011/06/10/obs-mobile-package-page-makeov...
1. Add “Project Status” on the project view page to indicate the overall real-time status of this project, possibly categorized as follows:
- 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 :) https://features.opensuse.org/306232 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 ?
Screenshot: http://susepaste.org/33683563
2. Organize the package view page like this: http://susepaste.org/45272178
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 otherwise.
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: http://susepaste.org/45395077 vs. collapsible view: http://susepaste.org/26703741
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 views.
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
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 27 June 2011 13:49:52 Adrian Schröter wrote:
Am Friday, 24. June 2011, 11:58:33 schrieb Justine Leng:
Hi all,
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: http://obsforandroid.wordpress.com/2011/06/10/obs-mobile-package-page-mak eover/
1. Add “Project Status” on the project view page to indicate the overall real-time status of this project, possibly categorized as follows:
- 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 :)
https://features.opensuse.org/306232
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 attribtute.
Screenshot: http://susepaste.org/33683563
2. Organize the package view page like this: http://susepaste.org/45272178
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 otherwise.
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: http://susepaste.org/45395077 vs. collapsible view: http://susepaste.org/26703741
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 views.
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
-- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
Am Monday, 27. June 2011, 14:23:17 schrieb Sascha Peilicke:
On Monday 27 June 2011 13:49:52 Adrian Schröter wrote:
Am Friday, 24. June 2011, 11:58:33 schrieb Justine Leng:
Hi all,
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: http://obsforandroid.wordpress.com/2011/06/10/obs-mobile-package-page-mak eover/
1. Add “Project Status” on the project view page to indicate the overall real-time status of this project, possibly categorized as follows:
- 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 :)
https://features.opensuse.org/306232
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 attribtute.
We can handle it via the model, but I don't see a reason why we should do an incompatible change (what would happen if we add this to project meta). -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 27 June 2011 14:33:14 Adrian Schröter wrote:
Am Monday, 27. June 2011, 14:23:17 schrieb Sascha Peilicke:
On Monday 27 June 2011 13:49:52 Adrian Schröter wrote:
Am Friday, 24. June 2011, 11:58:33 schrieb Justine Leng:
Hi all,
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: http://obsforandroid.wordpress.com/2011/06/10/obs-mobile-package-page -mak eover/
1. Add “Project Status” on the project view page to indicate the overall real-time status of this project, possibly categorized as follows:
- 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 :)
https://features.opensuse.org/306232
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 attribtute.
We can handle it via the model, but I don't see a reason why we should do an incompatible change (what would happen if we add this to project meta). Nothing really, until someone (e.g. webui) starts using it.
QualityCategory should be a seperate generic model with fixtures mapping to the proposed categories. Project and package models would have a foreign key on it. To stay with OBS' way of displaying data in meta files, we would add named attribute, maybe like this: <project name="foo" quality="stable"> ... </project> The webui could simply check if that new (XML) attribute is present in the meta XML and display sth. accordingly, like we do with project types. An independent model allows re-using it for other OBS primitives (think of builds, repos, whatever) and allows to (efficiently) count all stuff of a certain quality level. -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com
Am Monday, 27. June 2011, 14:54:55 schrieb Sascha Peilicke:
On Monday 27 June 2011 14:33:14 Adrian Schröter wrote:
Am Monday, 27. June 2011, 14:23:17 schrieb Sascha Peilicke:
On Monday 27 June 2011 13:49:52 Adrian Schröter wrote:
Am Friday, 24. June 2011, 11:58:33 schrieb Justine Leng:
Hi all,
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: http://obsforandroid.wordpress.com/2011/06/10/obs-mobile-package-page -mak eover/
1. Add “Project Status” on the project view page to indicate the overall real-time status of this project, possibly categorized as follows:
- 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 :)
https://features.opensuse.org/306232
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 attribtute.
We can handle it via the model, but I don't see a reason why we should do an incompatible change (what would happen if we add this to project meta). Nothing really, until someone (e.g. webui) starts using it.
QualityCategory should be a seperate generic model with fixtures mapping to the proposed categories. Project and package models would have a foreign key on it. To stay with OBS' way of displaying data in meta files, we would add named attribute, maybe like this:
<project name="foo" quality="stable">
that would already block all remote instances to use this project.
... </project>
The webui could simply check if that new (XML) attribute is present in the meta XML and display sth. accordingly, like we do with project types.
An independent model allows re-using it for other OBS primitives (think of builds, repos, whatever) and allows to (efficiently) count all stuff of a certain quality level.
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 27 June 2011, Adrian Schröter wrote:
<project name="foo" quality="stable"> that would already block all remote instances to use this project.
Why? just because we can't publish a proper DTD and make the xml parser use the version that this public instance is providing? Greetings, Dirk -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Wednesday, 29. June 2011, 21:06:23 schrieb Dirk Müller:
On Monday 27 June 2011, Adrian Schröter wrote:
<project name="foo" quality="stable"> that would already block all remote instances to use this project.
Why? just because we can't publish a proper DTD and make the xml parser use the version that this public instance is providing?
yes and because our backend code is picky and blocks jobs with unknown informations. So far we seperated critical informations for the build process in the xml meta data and additional data in the attributes (or where different write permissions exist). One can argue for a new concept here, but we should seperate in any case build relevant data from pure additional data to avoid api breakage and to avoid unneeded events to the backend (No need for scheduler runs on attribute changes for example). -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wednesday 29 June 2011, Adrian Schröter wrote:
One can argue for a new concept here, but we should seperate in any case build relevant data from pure additional data to avoid api breakage and to avoid unneeded events to the backend (No need for scheduler runs on attribute changes for example).
I think thats a fair point. Convinced! Thanks, Dirk -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 24.06.2011 17:58, Justine Leng wrote:
Hi all,
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: http://obsforandroid.wordpress.com/2011/06/10/obs-mobile-package-page-makeov...
1. Add “Project Status” on the project view page to indicate the overall real-time status of this project, possibly categorized as follows:
- 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.
Screenshot: http://susepaste.org/33683563
Hi Justine! The project status idea is good, so the users can clasify the state of a project faster, we could also show this in the software search on software.o.o. But to introduce this we need an agreement of the whole obs development team, so it is a bit out of scope for our mobile webui project. Let's implement this when the obs masters agreed on the backend implementation of it ;-)
2. Organize the package view page like this: http://susepaste.org/45272178
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 nice!
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
I'm not sure if such an api call already exists that shows packages that will trigger a rebuild. Probably that are the buildrequires from the specfile.
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: http://susepaste.org/45395077 vs. collapsible view: http://susepaste.org/26703741
Of course, we still need to convert those html webpage views to mobile views.
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
Greetings -- Thomas Schmidt (tom [at] opensuse.org) openSUSE Boosters Team "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Adrian Schröter -
Dirk Müller -
Justine Leng -
Sascha Peilicke -
Thomas Schmidt