checkbox-dev team mailing list archive

[Zygmunt Krynicki <zygmunt.krynicki@xxxxxxxxxxxxx>]

12:48 < kissiel> zyga, have you seen my mail about progress bar?
12:49 < kissiel> zyga, cause you were the one, to have additional 
content there IIRC
12:49 <@zyga> kissiel: no, not yet
12:49 <@zyga> looking
12:49 <@zyga> reading
12:49 <@zyga> kissiel: my opinions are:
12:50 <@zyga> kissiel: option 3 - too costly, it will load a lot of 
stuff while in reality we'll get microsoft minutes anyway if the test is 
not designed well
12:51 <@zyga> kissiel: option 2 - complex to understand what that means 
(as a user), I'd try to offer something trivial to "grasp" even if not 
perfectly accurate
12:51 < kissiel> zyga, but I remember that you wanted to have info about 
in-job progress
12:51 <@zyga> kissiel: option 1 - that would just mean we're swapping 
one progress bar for another, that's flushing user's trust into what the 
bar is
12:51 < kissiel> zyga, or I miss-decoded you :)
12:51 <@zyga> kissiel: yes, I'd do this instead:
12:51 <@zyga> kissiel: keep the global bar (that's what counts for the user)
12:52 <@zyga> kissiel: (optional for next story)
12:52 <@zyga> kissiel: have a number of slots the job may have (default 
one) and new API to bump the slot, slots are static (in the job 
definition) and are a side information, next to
              estimated_duration
12:52 <@zyga> kissiel: that's all, IMHO
12:52 <@zyga> kissiel: at the end of the day, you want to estimate the 
number of minutes left
12:53 <@zyga> kissiel: and have a visual indicator (without reading 
anything) where you are
12:53 <@zyga> ohs
12:53 <@zyga> kissiel: I'm a moron
12:53 <@zyga> kissiel: my options numbers don't line up with yours
12:53 <@zyga> kissiel: I want your option 1 now :)
12:53 < kissiel> hahaha
12:53 <@zyga> kissiel: and maybe do what I proposed later when we have 
complex, multi-stage jobs
12:53 <@zyga> kissiel: off-by-one error
12:54 < kissiel> zyga, allrighty :D
12:54 <@zyga> kissiel: I was fooled by 2 and 2-alt
12:54 < kissiel> zyga, sry for that
12:54 <@zyga> kissiel: no worries :)




W dniu 29.01.2015 o 13:03, Maciej Kisielewski pisze:
> Hello,
> There was a short discussion on IRC few days ago about how should we
> handle progress bar in the header for QML-native tests in Checkbox-Touch.
>
> I want to gather your opinion about the subject.
>
> Let's consider case when we have 10 jobs. Progress bar during 5th job should
> look similar to this:
> [####|     ] 5/10
>
> If we let native tests display progress bar in header we have following
> options:
>
> 1. Let it display progress of going through the list of jobs.
>
> 2. Let it display progress of within the job (current step)
>     For instance, consider having a job checking if gyroscope sensor
> works ok.
>     One of the steps would be to tilt left, one to tilt right, and so on.
>     Let's assume the job consists of 6 of those steps.
>     In this approach header progress bar would display [###|      ] 3/6
> on third
>     step, although there are 10 jobs total.
> 2-alt. Let it display progress of current job (internal) as an extension to
>     'ordinary' progress bar. I.e.
>       job: [####|     ] 5/10
>      step: [###|      ] 3/6
> 3. (looney) Let it gather info about steps from all tests, sum them up, and
>     display one progress bar, accounting for all steps. E.g. 10 jobs, 8
> of them
>     single-step and 2 of them 6-step.:
>      [####|     ] 7/20
>
> This only affects checkbox-touch, as header progress bar is not present in
> other front-ends (yet? ;-)
>
> I personally opt for 1. because it keeps everything straight-forward
> (for user
> and implementation).
>
>
> --
> Have a good one,
> Maciek