Treeherder and tbpl before it have very busy UIs. It is difficult to interact with them and view data on a mobile device. I do check build status on mobile and would like to view that shows high level information only. This view would pretty much only show the information in the builds status bar (outstanding jobs/tests, changeset id, time, eta) and allow me to expand a build for more information.
If anyone wants to take this, a possible starting point could be https://github.com/maurodoglio/mytreeherder I created it as a personal project on a weekend, so it's far from being production ready.
@mdoglio, Are you planning an completely new UI for mobile ? I am thinking of making current website ui compatible for mobile with simple changes. I) navbar, pinboard looks cluttered in mobile. II) Jobs and revision can be one below the other. reduce no. of revisions visible at once. III) initially hiding jobs, and slide down all jobs when user click on jobs list. etc., I am making sample UI layouts to align all these in a mobile view.
Just making the current api possible to use on a phone would be great. For example AFAIK it is impossible to do a retrigger on treeherder from a phone.
we are looking for basic use cases which are required in a mobile version of treeherder. A very basic use case as a mozilla developer is to check the status of pushes and see which jobs failed. So, if we make the required cases that should be implemented in mobile version, we can making layout of things.
FWIW with bug 1106905 landed on Firefox for Android the current TreeHerder view works for most things if you switch into desktop mode. While I'm sure a reduced-functionality mobile version would be handy too I would like to make sure that the desktop mode version won't be broken as a result (I don't see why it would but just in case...).
I like mdoglio's mytreeherder design to start with. A few of my opinions/thoughts: 1. We may need a few new APIs or adjustments a. aggregate data like counts of complete vs. not complete. We won't be able to show the completeness bar without that, or loading all the jobs into memory. b. counts of results: failures, passes, unclassified failures, etc 2. perhaps not make email a requirement. It'll be less "my" treeherder that way, but then sheriffs could use it for quick looks on their phone. But being able to set that would be really great for devs. 3. For each resultset make a button to load/display revisions and another for jobs. Display them stacked, not side-by-side, if both are visible. Or perhaps only let one or the other be visible at one time. Toggle between jobs/revisions?
Curious if Ed feels we should have a treeherder-mobile repo, or similar? Should we move Mauro's repo over, so dewgeek can base work off that location?
I think or makes more sense to have it in the same repo as treeherder. Otherwise when we search and replace refavtor, we could break the mobile app without realising it. Also there are likely to be shared assets.
Thanks Ed. So Rakesh, when you're to the point you will start changing code you could probably start by moving Mauro's relevant mytreeherder files to your local treeherder repo, into /mobile/ or similar.
I will make the mockups based on camd suggestions, pull the files to treeherder repo and start working on it when mockups are fine.
Oh! One thing I cannot do on the desktop view of TH using a mobile device is star an orange as something than a pre-existing intermittent. In order to dip this I need to hit the spacebar to select the failed job and there is no way to bring up the virtual keyboard to do that.
I have added one moqup of contents. https://email@example.com/0zKc1Vvw/p:a94b24c7a Suggestions please :)
In the above UI, I) Search can be used for searching Repo using Email. 2) Initially only repositories are loaded with percentage of completion, No. of jobs currently in progress, Last commit and it's time. 3) Either Jobs or revisions will be loaded will visible at once, based on click on <Revisions><Jobs> Tab 4) There should be a specific call for loading revisions or jobs based on repo
I think the default view (the one shown in your mockup) should also include the pusher of the commit, since that makes it much easier to find the push you care about.
So, the order should be i) revision text with timestamp ii) Author's Email on Left and Progress in Right (as in 81%, 71 in Progess) ?
Can we add a new Url for Job details ?
(In reply to Rakesh from comment #16) > So, the order should be > > i) revision text with timestamp > ii) Author's Email on Left and Progress in Right (as in 81%, 71 in Progess) ? That sounds good to me.
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #18) > (In reply to Rakesh from comment #16) > > So, the order should be > > > > i) revision text with timestamp > > ii) Author's Email on Left and Progress in Right (as in 81%, 71 in Progess) ? > > That sounds good to me. I have updated moqup to add email. It looks a little cluttered to have both of them in a single line. I added two lines
After discussing with mdoglio, we thought that we should have different pages for revisions and Jobs rather showing them in the same page in the slide down. I have made a preview for Revisions page https://email@example.com/0zKc1Vvw/p:a6b8c985e please Suggest changes.
Comment on attachment 8799209 [details] [review] [treeherder] KWierso:bug1066286 > mozilla:master I got bored this weekend and made this. Curious to hear your thoughts on this. The new mobile view automatically gets enabled if your screen width drops below 600px.
Comment on attachment 8799209 [details] [review] [treeherder] KWierso:bug1066286 > mozilla:master Looks interesting so far, not sure what else to say at this point :-)
Comment on attachment 8799209 [details] [review] [treeherder] KWierso:bug1066286 > mozilla:master Yeah, looks like a promising direction. Clicking on a job and having it show details could get... interesting... :) But Maybe not too bad. Just have a series of tabs or something? I dunno. I say keep going with it and see where it takes you. You may want to write-up a list of the workflows you want to support and explicitly aim just for those, disabling others. You can add more workflows later, perhaps? I guess one fear I'd have would be to prevent convoluting our existing UI code to support this. But I'm sure that's possible somehow.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.