Archive:GSOC 2011 OBS Mobile
tagline: From openSUSE
The GSOC 2011 (Google Summer of Code) Project OBS Mobile aims to improve and extend the mobile interface to the openSUSE Build Service. This is a mobile version of the webclient, making use of the jquery mobile framework. An Android app just wraps this interface and makes it available to the market. The current functionality is quite limited, so we should go ahead and extend it in the areas of reviewing of submit requests, displaying project build status...
Communication & resources
- IRC: freenode network, channel #opensuse-buildservice, #opensuse-project
- Mailing list: email@example.com (subscribe)
- Source code: http://gitorious.org/opensuse/build-service
- Production system / Staging system
- List and review submit requests, filter requests by type and state, show history, review state
- Enable actions on submit requests: accept, comment, force cancel, etc.
- The project / package page displays attributes, files, raw config, current status, and other packages that will trigger rebuild
- Enable the notification client to display new failures since last login (or based on user preferences) on the frontpage.
- Create proper documentation and test-suites for the mobile interface (as jQuery Mbile makes extensive use of AJAX)
- Enable users to link their profiles to their social media accounts and post status updates like microblogging
- Add search categories to projects / packages
- Sync mobile notifications to a desktop client
Mid-tern review (7/12/2011)
- Set up a local development instance of the build service webclient
- Created a local branch of the project on Gitorious: https://gitorious.org/~justineleng/opensuse/justineleng-build-service
- Accumulated community feedback on mobile view changes and enhancements, which provides general directions and specs for development for the next few weeks
- Coded changes in views (code for mobile view UI is practically done; just need to implement actions for those views in controller)
- Committed and pushed a batch of changes to master branch
- Kept detailed documentation in project blog: http://obsforandroid.wordpress.com/
To be done
- Code and implement new methods for each view change in controller
- Convert web-browser html views in project/package to mobile views
- Create test-suites for the mobile interface
- Continue with documentation
Created a branch of the project: https://gitorious.org/~justineleng/opensuse/justineleng-build-service. Will be sending merge requests from there.
Currently, the openSUSE Build Service (OBS) mobile client offers very limited functions. I would like to improve and extend the OBS mobile interface for Android. The goals include not only adding powerful functionalities such as sorting requests by different criteria and enabling real-time user actions, but also integrating a mobile test-suite for each new feature, and ultimately improving the overall user experience that will make the OBS mobile interface more efficient and convenient to use.
Currently, the OBS mobile client offers only a few basic functions such as browsing projects and packages, checking the build status, and listing requests. This project aims to improve and extend the functionalities of the OBS mobile interface for Android. The tasks include not only adding powerful functionalities such as sorting requests by different criteria and enabling real-time user actions, but also integrating a mobile browser-based test-suite for each new feature, and ultimately improving the overall user experience that will make the OBS mobile interface more efficient and convenient for developers to collaborate and release software directly on their Android devices. The OBS mobile interface makes use of the jQuery Mobile Framework (currently jQuery Mobile Alpha 3), which has a full suite of AJAX capabilities. An Android app wraps the mobile interface and makes it available to the market.
My efforts will concentrate on the following tasks, all of which aim to enhance the user experience of the OBS mobile interface to help developers create, collaborate, and release software more efficiently.
Add features to Requests
1. list and review all submit requests related to a user
2. sort requests by tags, types, times, and states
3. create a page that shows request history
4. create a page that shows real-time request states
5. enable actions on requests: comment, force cancel, etc.
Extend Projects / Packages
1. Enhance the existing searchfunctionality in projects / packages. Add search categories (see use case below):
- fresh packages + libraries (e.g., games)
- bleeding edge packages (e.g., zypp:svn)
- backports for older distributions (e.g., zypp:Backport)
- playground (e,g., all home projects)
Adding a filter function might be helpful, too. An “exclude projects” toggle in the mobile interface front-end would be a good start. This could be a specialized implementation of an --exclude-projects-matching <regexp> - and then the user will have a --search-only-matching <regexp> option for symmetry. 2. Project / package view will include the following tabs:
1). Attributes: display attributes of a project / package
2). Files: display all the files contained in a project / package 3). Config: display the initial / default configurations of a project / package
4). Related packages: list which packages (include version numbers) in the commit history of a package that will trigger it to rebuild.
5). Show project / package status:
- 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.
3. Enable time-stamped status updates (like tweets) on a package / project, reflecting the ongoing work on a project / package.This could be a simple mashup of OBS's API and Twitter's API, for example.
A user can choose to post the updates
1) on the project / package page only
2) on the project / package page and the user's profile page (and perhaps social media if linked).
The user can also choose to show only the current status on checkout or read all the status updates on a package (see use case 1 below).
Improve user interaction
1. Create a service that polls for build failures and shows notifications / flags.
2. Syncmobile notifications to a desktop client (and possibly send the user an SMS).
3. Enable users to link their profiles to their social media accounts (Twitter, Facebook, etc.) and post status updates to chosen services.
Documentation and testing
Create proper documentation and tests for the above-mentioned components.
Use Case 1: status updates
A team of four developers are collaborating on a game project.
1. Jesse is updating UrbanTerror:Workbench:Factory to 1.2 and disables publish on the whole project until the actual release date. He posts a status message on the OBS mobile interface,which also updates his linked Twitter account: “04/03/2011 12:56pm Disabled publish pending1.2 release.”
2. Alex is triaging breakages in UrbanTerror:Workbench:Factory and marks packages without checking them out before assigning work to team members Daniel and Linda. He easily does this by posting a status update message: “04/04/2011 03:14pm osc mark -m 'broken by input.device changes' UrbanTerror:Workbench:Factory Preferences."
3. Linda is fixing a breakage in UrbanTerror:Workbench:Factorypreferences, and locks the package with status update "04/05/2011 10:29am osc co -l -m '20110405 - fixing build failure due to input.device changes' UrbanTerror:Workbench:Factory preferences."
Use Case 2: more powerful search function in projectlist
1. Ben wants to find the latest packages / projects related to games. He types “game” in the project search box, taps “fresh packages” in the category option, and sees a list of the most recentpackages / projects return.
2. Craig wants to find the libzypp/zypper backport repository. He searches for “zypp” with a category of “backport,” which immediately returns the repository he was looking for.
3. Tracy is interested in checking out a project, and she sees the current project status is shown to be “testing.” She thinks it might be a better idea to stop back a few days later to check out a stable version of the project.
Use Case 3: enhanced experience of submitting requests
Ted would like to add a chat feature to “Spring Engine,” so he submits a request from his Android phone. He tags this request with “spring engine.” While the request state is pending, Tedshares his request on his Twitter account and blog status (which he has previously linked), inviting more developers to join the discussion. A day later, he receives an SMS notification on his Android phone, alerting him that his request has received two votes from the community and three developers have joined the discussion. Two days later, Ted receives another SMS saying his request has been accepted. He taps to share more design ideas on Twitter and encourage more community discussions.
Use Case 4: enhanced experience of searching / sorting requests
Andy opens up the OBS mobile interface on his Android phone, searches requests with the tag “desktop,” and sees two full pages ofsubmitted requests. He wants to see the latest request, so he sorts the requests by submit times, and finds the most recent request was submitted two weeks ago with a proposal to enable Dolphin open PERL documents in Kwrite. This request status is “unconfirmed,” and Andy is interested in the latest accepted request, so he goes back and sorts the requests again by their statuses. The latest accepted request is “Update of KDE integration to KDE4 in openSUSE 11.3.” Andy reads the discussion and finds the newly added OOo quickstarterinteresting, and he decides to check out the package with a simple tap on his phone. +++
1. This project will help developers create and release projects / packages more quickly and conveniently through the OBS mobile client on their Android devices.
2. This project will greatly promote communication and collaboration among developers.
3. This project will also help make it easier for developers to deploy projects / packages to clients by configuring the mobile interface to their needs. +++
1. Implementing the entire user interface in a mobile phone might be too time-consuming. We might consider doing this primarily for the parts where a phone makes a good tool for the buildservice.
2. Be careful with version controls, merge conflicts, etc. We might consider preparing changes in a branched project and then requesting to have the changes merged back.
3. Default.properties, a file automatically generated by Android Tools, should not be modified, or changes will be erased.
4. Developers working on this project should be using the same versions of technologies to ensure consistency and compatibility.
5. The app might be slower than if it had been developed in the native way. The app size might be a concern.
6. In Android, most of the time, for each page navigation, the developer will have to add an activity indicator, if there are a lot of controls in view.
7. The web browser-based UI might seem foreign compared to any native UI, e.g., the app may not look like an Android app on Android, or an iPhone app on the iPhone, etc. It will be something unique, but also foreign and unfamiliar in terms of look and function.
8. The mobile UI needs a browser-based (or rendering-engine based) test-suite besides unit or fuctional testing.
9. There is no easy solution when an app doesn't deploy properly on a platform or individual device.
Now - April 26 (preparation)
- Set up openSUSE 11.4 in my local environment
- Thoroughly familiarize myself with OBS's architecture and workflows.
- Study the customized files of obs-client-android available on Gitorious.
- Study the source code of Hermes
- Familiarize myself with Ruby on Rails, jQuery, HTML5, and Git
- Install and test has_mobile_views plugin (from Andre Duffeck's GitHub repositories) in my local environment, which enables rendering special versions of views and partials for mobile devices by detecting those devices using the browser's HTTP_USER_AGENT string. Make sure it's working correctly.
- Set up a local instance of the build service web client
April 27- May 23 (before the official coding time):
- Set up a local infrastructure that will allow me to communicate with the Build Service API via XML over HTTP very easily, and enable me to push new versions every time I add something.
- Do hands-on coding with Ruby on Rails, HTML5, and jQuery to become better at these tools.
- Keep in constant touch with my mentor and the openSUSE community. I will actively participate in IRC discussions and mailing lists to explore ideas and refine my plans.
- With the help of my mentor and the community, I will become fairly clear about my goals as well as the final implementations that need to be done on the OBS mobile interface.
May 24- June 14 (official coding period starts):
- Define all the required classes and objects
- Write the code to list requests, sort requests, show request history, show request status, enables user actions
- Test and document existing code thoroughly
- Release often and actively seek feedback from the community
- I hope to complete implementing functionalities for submit requests by this date.
June 15- July 11
- Customize the source code of Hermes to display failures since a user's last login
- Reuse the code from submit requests to show attributes, files, configurations, statuses, and related packages to the project / package view (this should not take much time as most of the functionality has been implemented earlier).
- Determine algorithms used to categorize and filter projects / packages. Then, write the code to implement the algorithms.
- Release often and actively seek feedback from the community.
- Document the algorithms. Test each module of the modified source code.
July 12th – Mid-term Evaluation
July 12- July 25:
- Write a mashup function that combines OBS's API with Twitter's API to enable status updates
- Mash up OBS's API with social networking sites' APIs to connect users' accounts
- Test and document the API mashups. Release them to the community and seek feedback.
July 26 – August 8
- Determine the algorithms to flag build failures and sync mobile to desktop clients
- A system that notifies users of build failures and send out alerts to desktop client and to mobile client via SMS is written.
- Test and document the source code thoroughly.
- Release to the community and seek feedback.
August9 -August 22:
- Making further changes in the code to improve the functionality, exception handling, bug removal.
- Further refine tests (perhaps make use of a mobile test-suite) and documentation for the whole project.