RFC: Hob 1.2 design

RFC: Hob 1.2 design

[Wang, Shane]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

Hi, all,

Belen has a new video for Hob2 workflow and design.

https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov

Please comment.

Thanks.
--
Shane

[-- Attachment #2: Type: text/html, Size: 8932 bytes --]

Re: Hob 1.2 design

[Stewart, David C]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Belen - nice work!  This just gets better all the time.  I really like the enhancements to the work flow.

Quick question - around 6:40 in the video, once you successfully build there is a "Deploy Image" button. Then at 7:44 there is a "Write to Storage" button. Are these both doing the same thing?

Thank you for making something so functional and so beautiful.

Dave

From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Wang, Shane
Sent: Wednesday, February 01, 2012 9:39 AM
To: yocto@yoctoproject.org
Subject: [yocto] RFC: Hob 1.2 design

Hi, all,

Belen has a new video for Hob2 workflow and design.

https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov

Please comment.

Thanks.
--
Shane

[-- Attachment #2: Type: text/html, Size: 7344 bytes --]

Re: RFC: Hob 1.2 design

[Scott Garman]

On 01/31/2012 05:39 PM, Wang, Shane wrote:
> Hi, all,
>
> Belen has a new video for Hob2 workflow and design.
>
> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov
>
> Please comment.

I'm pretty amazed with this. The workflow seems clear and each screen 
provides just the right bits of information the user would be interested 
in seeing. Outstanding!

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: RFC: Hob 1.2 design

[Jack Mitchell]

On 01/02/12 17:28, Scott Garman wrote:
> On 01/31/2012 05:39 PM, Wang, Shane wrote:
>> Hi, all,
>>
>> Belen has a new video for Hob2 workflow and design.
>>
>> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov
>>
>> Please comment.
>
> I'm pretty amazed with this. The workflow seems clear and each screen 
> provides just the right bits of information the user would be 
> interested in seeing. Outstanding!
>
> Scott
>

I concur, it looks fantastic - well done!

It covers a lot more bases than I thought it would. Even if you still 
like to do the build via CLI it gives a fantastic overview of the system 
you're building as a whole, and even better, a dependency tree for why 
certain packages are being included in the build.

Re: Hob 1.2 design

[Barros Pena, Belen]

You are right, Dave. "Deploy image" and "Write to storage" are the same thing. I meant to use "Write to storage" everywhere (it seemed a more accurate description), but a "Deploy" slipped through!

Thanks for the nice feedback.

Belen

From: "Stewart, David C" <david.c.stewart@intel.com<mailto:david.c.stewart@intel.com>>
Date: Wed, 1 Feb 2012 03:15:55 +0000
To: "Wang, Shane" <shane.wang@intel.com<mailto:shane.wang@intel.com>>, "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] Hob 1.2 design

Belen – nice work!  This just gets better all the time.  I really like the enhancements to the work flow.

Quick question – around 6:40 in the video, once you successfully build there is a “Deploy Image” button. Then at 7:44 there is a “Write to Storage” button. Are these both doing the same thing?

Thank you for making something so functional and so beautiful.

Dave

From: yocto-bounces@yoctoproject.org<mailto:yocto-bounces@yoctoproject.org> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Wang, Shane
Sent: Wednesday, February 01, 2012 9:39 AM
To: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: [yocto] RFC: Hob 1.2 design

Hi, all,

Belen has a new video for Hob2 workflow and design.

https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov

Please comment.

Thanks.
--
Shane
_______________________________________________ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: RFC: Hob 1.2 design

[Joshua Lock]

On 31/01/12 17:39, Wang, Shane wrote:
> Hi, all,
>
> Belen has a new video for Hob2 workflow and design.
>
> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov

It just came to my attention through another channel that the 
description column of the packages table is no longer present.

There had been some discussion about how to show relevant description 
information in that column, so I'm surprised to see it go.

Belen, I assume from a design perspective this field was removed as it 
didn't show anything particularly useful? If we have useful data to 
include in that field is there a more appropriate way to integrate it 
into the UI? Perhaps a tooltip? Or an information overlay as has been 
used in other areas of the design?

I'm concerned that if we give the user a list of packages without any 
more information we aren't making it easy for them to build an OS image 
without already understanding exactly all of the components they need - 
thoughts?

Cheers,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: RFC: Hob 1.2 design

[Barros Pena, Belen]

Hi Joshua,

Additional package details appear on clicking the package name using an
information bubble. The bubble is also dismissed on click using a 'close'
button. This functionality is shown on the first video (not on the second
one: I skipped it to keep it short).

Cheers

Belen

On 06/02/2012 21:32, "Joshua Lock" <josh@linux.intel.com> wrote:

>On 31/01/12 17:39, Wang, Shane wrote:
>> Hi, all,
>>
>> Belen has a new video for Hob2 workflow and design.
>>
>> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov
>
>It just came to my attention through another channel that the
>description column of the packages table is no longer present.
>
>There had been some discussion about how to show relevant description
>information in that column, so I'm surprised to see it go.
>
>Belen, I assume from a design perspective this field was removed as it
>didn't show anything particularly useful? If we have useful data to
>include in that field is there a more appropriate way to integrate it
>into the UI? Perhaps a tooltip? Or an information overlay as has been
>used in other areas of the design?
>
>I'm concerned that if we give the user a list of packages without any
>more information we aren't making it easy for them to build an OS image
>without already understanding exactly all of the components they need -
>thoughts?
>
>Cheers,
>Joshua
>-- 
>Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: RFC: Hob 1.2 design

[Joshua Lock]

Hi Belen,

Thanks for clarifying.

Shane - I noticed at least one bug has been closed because the second 
video didn't show the features (#1804) - seems like this isn't what was 
intended by features 'disappearing' in the latest video.

http://bugzilla.pokylinux.org/show_bug.cgi?id=1804

Cheers,
Joshua

On 07/02/12 03:23, Barros Pena, Belen wrote:
> Hi Joshua,
>
> Additional package details appear on clicking the package name using an
> information bubble. The bubble is also dismissed on click using a 'close'
> button. This functionality is shown on the first video (not on the second
> one: I skipped it to keep it short).
>
> Cheers
>
> Belen
>
> On 06/02/2012 21:32, "Joshua Lock"<josh@linux.intel.com>  wrote:
>
>> On 31/01/12 17:39, Wang, Shane wrote:
>>> Hi, all,
>>>
>>> Belen has a new video for Hob2 workflow and design.
>>>
>>> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov
>>
>> It just came to my attention through another channel that the
>> description column of the packages table is no longer present.
>>
>> There had been some discussion about how to show relevant description
>> information in that column, so I'm surprised to see it go.
>>
>> Belen, I assume from a design perspective this field was removed as it
>> didn't show anything particularly useful? If we have useful data to
>> include in that field is there a more appropriate way to integrate it
>> into the UI? Perhaps a tooltip? Or an information overlay as has been
>> used in other areas of the design?
>>
>> I'm concerned that if we give the user a list of packages without any
>> more information we aren't making it easy for them to build an OS image
>> without already understanding exactly all of the components they need -
>> thoughts?
>>
>> Cheers,
>> Joshua
>> --
>> Joshua Lock
>>          Yocto Project "Johannes factotum"
>>          Intel Open Source Technology Centre
>

-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: RFC: Hob 1.2 design

[Barros Pena, Belen]

Just to clarify: videos show relevant functionality to a specific design
piece. The fact that a video does not show something it doesn't mean the
functionality has gone away. If I showed everything on each video they
would be very very long (and very very boring) videos.  I hope this
explains. 

Given the time constraints we have, the little design documentation I am
producing is incomplete. Therefore, it is very important that if you have
any questions, doubts, thoughts, feedback, general comments etc about the
Hob UI, you get in touch with me. Even if the question sounds very small
or trivial: that's what I am here for.

Cheers

Belen



On 07/02/2012 16:17, "Joshua Lock" <josh@linux.intel.com> wrote:

>Hi Belen,
>
>Thanks for clarifying.
>
>Shane - I noticed at least one bug has been closed because the second
>video didn't show the features (#1804) - seems like this isn't what was
>intended by features 'disappearing' in the latest video.
>
>http://bugzilla.pokylinux.org/show_bug.cgi?id=1804
>
>Cheers,
>Joshua
>
>On 07/02/12 03:23, Barros Pena, Belen wrote:
>> Hi Joshua,
>>
>> Additional package details appear on clicking the package name using an
>> information bubble. The bubble is also dismissed on click using a
>>'close'
>> button. This functionality is shown on the first video (not on the
>>second
>> one: I skipped it to keep it short).
>>
>> Cheers
>>
>> Belen
>>
>> On 06/02/2012 21:32, "Joshua Lock"<josh@linux.intel.com>  wrote:
>>
>>> On 31/01/12 17:39, Wang, Shane wrote:
>>>> Hi, all,
>>>>
>>>> Belen has a new video for Hob2 workflow and design.
>>>>
>>>> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov
>>>
>>> It just came to my attention through another channel that the
>>> description column of the packages table is no longer present.
>>>
>>> There had been some discussion about how to show relevant description
>>> information in that column, so I'm surprised to see it go.
>>>
>>> Belen, I assume from a design perspective this field was removed as it
>>> didn't show anything particularly useful? If we have useful data to
>>> include in that field is there a more appropriate way to integrate it
>>> into the UI? Perhaps a tooltip? Or an information overlay as has been
>>> used in other areas of the design?
>>>
>>> I'm concerned that if we give the user a list of packages without any
>>> more information we aren't making it easy for them to build an OS image
>>> without already understanding exactly all of the components they need -
>>> thoughts?
>>>
>>> Cheers,
>>> Joshua
>>> --
>>> Joshua Lock
>>>          Yocto Project "Johannes factotum"
>>>          Intel Open Source Technology Centre
>>
>
>-- 
>Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: RFC: Hob 1.2 design

[Barros Pena, Belen]

Hi Shane and team,

In general all sounds good. I just have a couple of small comments, which I've added below.

Belen

From: "Wang, Shane" <shane.wang@intel.com<mailto:shane.wang@intel.com>>
Date: Fri, 3 Feb 2012 05:29:57 +0000
To: "Xu, Dongxiao" <dongxiao.xu@intel.com<mailto:dongxiao.xu@intel.com>>, "Belen Barros Pena (Intel)" <belen.barros.pena@intel.com<mailto:belen.barros.pena@intel.com>>, "Lu, Lianhao" <lianhao.lu@intel.com<mailto:lianhao.lu@intel.com>>
Cc: "Eggleton, Paul" <paul.eggleton@intel.com<mailto:paul.eggleton@intel.com>>, "Purdie, Richard" <richard.purdie@intel.com<mailto:richard.purdie@intel.com>>, "Zhang, Jessica" <jessica.zhang@intel.com<mailto:jessica.zhang@intel.com>>, "Lock, Joshua" <joshua.lock@intel.com<mailto:joshua.lock@intel.com>>, "Liu, Song" <song.liu@intel.com<mailto:song.liu@intel.com>>, "Stewart, David C" <david.c.stewart@intel.com<mailto:david.c.stewart@intel.com>>, "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: RE: RFC: Hob 1.2 design

Dongxiao and I have a discussion on that again.

Belen, please ignore the issue for the deployment button below, and we have several suggestions.

1. To make the Packages Screen and the Packages dialog the same.
The Packages Screen is shown after users click “Build packages”. That is one step of the process.
However, the content shown in the Package dialog is all what we have built out last time. It is very possible users start from there and don’t want to go back to the Image configuration screen and click “Build Image”.

Sorry, I am not sure I understand. What you seem to be saying is that we will eliminate the 'View packages' button from the Image configuration screen and the Packages dialogue. Users will access packages information via the 'Build packages' option, which will bring them to the Packages screen. Is this correct?

2. As mentioned in my last email, we want to add “Clean” in the GUI. The reason is the build will fail, say, do_fetch, then we have an option to allow users to clean what we built out and rebuild. Otherwise, the sstate could be reused for the next build. Users can do it by running “bitbake –c cleanall” in the command line. But we hope to provide this feature in the GUI.
If you agree the above, then the action “Clean” is for a recipe or multiple recipes, and clicking “Clean” will go to the screen at 4:00, since cleaning includes some tasks.
Then we could make the Recipes dialog to be a screen, do you agree?

Yes: I agree with you. Making Recipes a screen instead of a dialogue seems like a good solution. However, I am not sure the 'Clean' function should be in the Recipes screen: it should probably be an option that is displayed when the build fails. If you select it you go to the screen at 4:00 to provide information about the cleaning tasks and once they are done, you get the Recipes screen ready for you to build again. I think this 'build failed' scenario is very important, and I would like to design it carefully. Would  it be ok if I work on it this week and send you some suggestions?

The other reason is users can view recipes and click “Build Packages”, no need go back to the Image configuration screen.
The use case is:
1) View Recipes in the Image configuration -> the Recipes screen -> Select recipes and Build packages -> Log -> the Packages screen …
2) View Recipes in the Image configuration -> the Recipes screen -> Select recipes and Build packages -> Log -> Failure -> Go back to the Recipes screen -> Clean something -> Log -> the Recipes screen -> Build packages again -> Log -> Success -> the Packages screen …
3) View Recipes in the Image configuration -> the Recipes screen -> Select recipes -> Go back to the Image configuraion -> “Build Image”
4) Nothing want to view in the Image configuration after choosing “base image” -> “Build packages” -> Log -> the Packages screen …
5) Nothing want to view in the Image configuration after choosing “base image” -> “Build packages” -> Log -> Failure -> Go back to the Image configuration -> View Recipes -> the Recipes screen -> Clean something -> Log -> the Recipe screen -> …
6) Nothing want to view in the Image configuration after choosing “base image” -> “Build Image” -> Log -> the Image details …
and so on…

This seems to make sense. Just a small comment about the use case number 3. I think the Recipes screen should have 2 actions: "build packages" and "build image", so that users who want to build an image directly from the Recipes screen don't need to go back to the Image configuration screen in order to build the image.

3. When build is failed, there is a “Back” button. But go back to where is determined by where you come from.

I'll keep this in mind when designing the 'build failed' scenario.

4. After users open an image by “My images”, some time there should not be a “Save Template” because we don’t have build process.
Let’s show “Save Template” when “Congratulations! Your image is ready!” is shown, OK?

This sounds ok to me. Should we have a 'save as template' option in the Image configuration screen? Or will we just have it in the Image details screen when you get there after completing the build process?

5. In the Image details screen, “Settings” is obviously not good to be shown there. Can we remove “Load Template”? Because it will initiate a new build. Let’s ask users to click “Build new image” to be on the Image configuration and click “Load Template”.
We just keep “My Images” in the last screen (the Image details screen), is it OK?
And remove “Edit Packages” and “Edit Configuration”, if the build process is not executed this time. (ditto for “Save Template” in 4.)

Happy with this.

6. In Josh’s email, FRI 2 image can also be run, though it is an image for real machine. Can we keep two buttons “Run” and “Deploy” on the Image details screen and let uses decide what he/she wants? I admit an error possibly happens if the image doesn’t match the action, but we just report the error.

Not so happy with this one ;) If an option is going to generate an error when selected, it should not be there at all. GUI's must be defensive: they must prevent user errors. This is a fundamental principle of interaction design. We should only present the  'Run' (on qemu) option if the image is suitable for qemu running. We should only display the 'Deploy' option for live images. If there is no way to reliably determine what type of image we are dealing with and which options are suitable for them, the 'Run' and 'Deploy' functionality should not be there at all. Better wait until we find a work around.

Having said that, it seems to me that using the file extension to determine what's the appropriate action for each image should work the vast majority of times. If someone has changed the extension of the image, well, that would be an edge case (how likely are people to do that?), and we should not get into the trap of designing for the edge case, which is what we would be doing if we were to display both 'run' and 'deploy' for all images.

Thoughts?
Thanks.
--
Shane

From: Xu, Dongxiao
Sent: Friday, February 03, 2012 8:57 AM
To: Wang, Shane; Barros Pena, Belen; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: RE: RFC: Hob 1.2 design

One more from me that, Hob may work as a deploy tool, and in the new movie, the approach is to select “My images” and then click deploy button. I think normal user may not have such knowledge. I am still wondering if adding a “deploy” button in the tool bar?

Thanks,
Dongxiao

From: Wang, Shane
Sent: Friday, February 03, 2012 8:26 AM
To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: RE: RFC: Hob 1.2 design

I get one more:

In the Image details screen, after opening an image file by clicking “My images”, we don’t allow to “Edit Package”, I think.
Because with an image only, we can’t generate the packages from it, you can’t assume there is a build directory (tmp/), is my understanding correct?

--
Shane
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: RFC: Hob 1.2 design

[Barros Pena, Belen]

Hi Shane and team,

Thanks for the suggestions. Loads of interesting stuff there.

I'll take some time to look at them in detail and come back to you next week.

Have a great weekend.

Belen

From: "Wang, Shane" <shane.wang@intel.com<mailto:shane.wang@intel.com>>
Date: Fri, 3 Feb 2012 05:29:57 +0000
To: "Xu, Dongxiao" <dongxiao.xu@intel.com<mailto:dongxiao.xu@intel.com>>, "Belen Barros Pena (Intel)" <belen.barros.pena@intel.com<mailto:belen.barros.pena@intel.com>>, "Lu, Lianhao" <lianhao.lu@intel.com<mailto:lianhao.lu@intel.com>>
Cc: "Eggleton, Paul" <paul.eggleton@intel.com<mailto:paul.eggleton@intel.com>>, "Purdie, Richard" <richard.purdie@intel.com<mailto:richard.purdie@intel.com>>, "Zhang, Jessica" <jessica.zhang@intel.com<mailto:jessica.zhang@intel.com>>, "Lock, Joshua" <joshua.lock@intel.com<mailto:joshua.lock@intel.com>>, "Liu, Song" <song.liu@intel.com<mailto:song.liu@intel.com>>, "Stewart, David C" <david.c.stewart@intel.com<mailto:david.c.stewart@intel.com>>, "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: RE: RFC: Hob 1.2 design

Dongxiao and I have a discussion on that again.

Belen, please ignore the issue for the deployment button below, and we have several suggestions.

1. To make the Packages Screen and the Packages dialog the same.
The Packages Screen is shown after users click “Build packages”. That is one step of the process.
However, the content shown in the Package dialog is all what we have built out last time. It is very possible users start from there and don’t want to go back to the Image configuration screen and click “Build Image”.

2. As mentioned in my last email, we want to add “Clean” in the GUI. The reason is the build will fail, say, do_fetch, then we have an option to allow users to clean what we built out and rebuild. Otherwise, the sstate could be reused for the next build. Users can do it by running “bitbake –c cleanall” in the command line. But we hope to provide this feature in the GUI.
If you agree the above, then the action “Clean” is for a recipe or multiple recipes, and clicking “Clean” will go to the screen at 4:00, since cleaning includes some tasks.
Then we could make the Recipes dialog to be a screen, do you agree?
The other reason is users can view recipes and click “Build Packages”, no need go back to the Image configuration screen.
The use case is:
1) View Recipes in the Image configuration -> the Recipes screen -> Select recipes and Build packages -> Log -> the Packages screen …
2) View Recipes in the Image configuration -> the Recipes screen -> Select recipes and Build packages -> Log -> Failure -> Go back to the Recipes screen -> Clean something -> Log -> the Recipes screen -> Build packages again -> Log -> Success -> the Packages screen …
3) View Recipes in the Image configuration -> the Recipes screen -> Select recipes -> Go back to the Image configuraion -> “Build Image”
4) Nothing want to view in the Image configuration after choosing “base image” -> “Build packages” -> Log -> the Packages screen …
5) Nothing want to view in the Image configuration after choosing “base image” -> “Build packages” -> Log -> Failure -> Go back to the Image configuration -> View Recipes -> the Recipes screen -> Clean something -> Log -> the Recipe screen -> …
6) Nothing want to view in the Image configuration after choosing “base image” -> “Build Image” -> Log -> the Image details …
and so on…

3. When build is failed, there is a “Back” button. But go back to where is determined by where you come from.

4. After users open an image by “My images”, some time there should not be a “Save Template” because we don’t have build process.
Let’s show “Save Template” when “Congratulations! Your image is ready!” is shown, OK?

5. In the Image details screen, “Settings” is obviously not good to be shown there. Can we remove “Load Template”? Because it will initiate a new build. Let’s ask users to click “Build new image” to be on the Image configuration and click “Load Template”.
We just keep “My Images” in the last screen (the Image details screen), is it OK?
And remove “Edit Packages” and “Edit Configuration”, if the build process is not executed this time. (ditto for “Save Template” in 4.)

6. In Josh’s email, FRI 2 image can also be run, though it is an image for real machine. Can we keep two buttons “Run” and “Deploy” on the Image details screen and let uses decide what he/she wants? I admit an error possibly happens if the image doesn’t match the action, but we just report the error.

Thoughts?
Thanks.
--
Shane

From: Xu, Dongxiao
Sent: Friday, February 03, 2012 8:57 AM
To: Wang, Shane; Barros Pena, Belen; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: RE: RFC: Hob 1.2 design

One more from me that, Hob may work as a deploy tool, and in the new movie, the approach is to select “My images” and then click deploy button. I think normal user may not have such knowledge. I am still wondering if adding a “deploy” button in the tool bar?

Thanks,
Dongxiao

From: Wang, Shane
Sent: Friday, February 03, 2012 8:26 AM
To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: RE: RFC: Hob 1.2 design

I get one more:

In the Image details screen, after opening an image file by clicking “My images”, we don’t allow to “Edit Package”, I think.
Because with an image only, we can’t generate the packages from it, you can’t assume there is a build directory (tmp/), is my understanding correct?

--
Shane
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: RFC: Hob 1.2 design

[Wang, Shane]

[-- Attachment #1: Type: text/plain, Size: 4655 bytes --]

Dongxiao and I have a discussion on that again.

Belen, please ignore the issue for the deployment button below, and we have several suggestions.

1. To make the Packages Screen and the Packages dialog the same.
The Packages Screen is shown after users click "Build packages". That is one step of the process.
However, the content shown in the Package dialog is all what we have built out last time. It is very possible users start from there and don't want to go back to the Image configuration screen and click "Build Image".

2. As mentioned in my last email, we want to add "Clean" in the GUI. The reason is the build will fail, say, do_fetch, then we have an option to allow users to clean what we built out and rebuild. Otherwise, the sstate could be reused for the next build. Users can do it by running "bitbake -c cleanall" in the command line. But we hope to provide this feature in the GUI.
If you agree the above, then the action "Clean" is for a recipe or multiple recipes, and clicking "Clean" will go to the screen at 4:00, since cleaning includes some tasks.
Then we could make the Recipes dialog to be a screen, do you agree?
The other reason is users can view recipes and click "Build Packages", no need go back to the Image configuration screen.
The use case is:
1) View Recipes in the Image configuration -> the Recipes screen -> Select recipes and Build packages -> Log -> the Packages screen ...
2) View Recipes in the Image configuration -> the Recipes screen -> Select recipes and Build packages -> Log -> Failure -> Go back to the Recipes screen -> Clean something -> Log -> the Recipes screen -> Build packages again -> Log -> Success -> the Packages screen ...
3) View Recipes in the Image configuration -> the Recipes screen -> Select recipes -> Go back to the Image configuraion -> "Build Image"
4) Nothing want to view in the Image configuration after choosing "base image" -> "Build packages" -> Log -> the Packages screen ...
5) Nothing want to view in the Image configuration after choosing "base image" -> "Build packages" -> Log -> Failure -> Go back to the Image configuration -> View Recipes -> the Recipes screen -> Clean something -> Log -> the Recipe screen -> ...
6) Nothing want to view in the Image configuration after choosing "base image" -> "Build Image" -> Log -> the Image details ...
and so on...

3. When build is failed, there is a "Back" button. But go back to where is determined by where you come from.

4. After users open an image by "My images", some time there should not be a "Save Template" because we don't have build process.
Let's show "Save Template" when "Congratulations! Your image is ready!" is shown, OK?

5. In the Image details screen, "Settings" is obviously not good to be shown there. Can we remove "Load Template"? Because it will initiate a new build. Let's ask users to click "Build new image" to be on the Image configuration and click "Load Template".
We just keep "My Images" in the last screen (the Image details screen), is it OK?
And remove "Edit Packages" and "Edit Configuration", if the build process is not executed this time. (ditto for "Save Template" in 4.)

6. In Josh's email, FRI 2 image can also be run, though it is an image for real machine. Can we keep two buttons "Run" and "Deploy" on the Image details screen and let uses decide what he/she wants? I admit an error possibly happens if the image doesn't match the action, but we just report the error.

Thoughts?
Thanks.
--
Shane

From: Xu, Dongxiao
Sent: Friday, February 03, 2012 8:57 AM
To: Wang, Shane; Barros Pena, Belen; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org
Subject: RE: RFC: Hob 1.2 design

One more from me that, Hob may work as a deploy tool, and in the new movie, the approach is to select "My images" and then click deploy button. I think normal user may not have such knowledge. I am still wondering if adding a "deploy" button in the tool bar?

Thanks,
Dongxiao

From: Wang, Shane
Sent: Friday, February 03, 2012 8:26 AM
To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org
Subject: RE: RFC: Hob 1.2 design

I get one more:

In the Image details screen, after opening an image file by clicking "My images", we don't allow to "Edit Package", I think.
Because with an image only, we can't generate the packages from it, you can't assume there is a build directory (tmp/), is my understanding correct?

--
Shane

[-- Attachment #2: Type: text/html, Size: 19145 bytes --]

Re: RFC: Hob 1.2 design

[Xu, Dongxiao]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

One more from me that, Hob may work as a deploy tool, and in the new movie, the approach is to select "My images" and then click deploy button. I think normal user may not have such knowledge. I am still wondering if adding a "deploy" button in the tool bar?

Thanks,
Dongxiao

From: Wang, Shane
Sent: Friday, February 03, 2012 8:26 AM
To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org
Subject: RE: RFC: Hob 1.2 design

I get one more:

In the Image details screen, after opening an image file by clicking "My images", we don't allow to "Edit Package", I think.
Because with an image only, we can't generate the packages from it, you can't assume there is a build directory (tmp/), is my understanding correct?

--
Shane

[-- Attachment #2: Type: text/html, Size: 5776 bytes --]

Re: RFC: Hob 1.2 design

[Xu, Dongxiao]

[-- Attachment #1: Type: text/plain, Size: 26922 bytes --]

My feedbacks in "blue".

Thanks,
Dongxiao

From: Wang, Shane
Sent: Thursday, February 02, 2012 8:48 PM
To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org
Subject: Re: RFC: Hob 1.2 design

Please see my feedbacks embedded in red.

Thanks.
--
Shane
From: "Wang, Shane" <shane.wang@intel.com<mailto:shane.wang@intel.com>>
Date: Wed, 1 Feb 2012 14:49:38 +0000
To: "Belen Barros Pena (Intel)" <belen.barros.pena@intel.com<mailto:belen.barros.pena@intel.com>>, "Xu, Dongxiao" <dongxiao.xu@intel.com<mailto:dongxiao.xu@intel.com>>, "Lu, Lianhao" <lianhao.lu@intel.com<mailto:lianhao.lu@intel.com>>
Subject: RE: Hob 1.2 next steps

<!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Times New Roman","serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin:0cm; margin-bottom:.0001pt; text-indent:21.0pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:SimSun;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal; font-family:"Courier New"; color:blue; font-weight:normal; font-style:normal; text-decoration:none none;} span.EmailStyle22 {mso-style-type:personal; font-family:"Courier New"; color:blue; font-weight:normal; font-style:normal; text-decoration:none none;} span.EmailStyle23 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1335497491; mso-list-template-ids:-608031632;} @list l1 {mso-list-id:1405881917; mso-list-type:hybrid; mso-list-template-ids:-2065393162 -1271618664 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} @list l1:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt;} @list l1:level2 {mso-level-number-format:alpha-lower; mso-level-text:"%2\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:42.0pt; text-indent:-21.0pt;} @list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:63.0pt; text-indent:-21.0pt;} @list l1:level4 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:84.0pt; text-indent:-21.0pt;} @list l1:level5 {mso-level-number-format:alpha-lower; mso-level-text:"%5\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:105.0pt; text-indent:-21.0pt;} @list l1:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:126.0pt; text-indent:-21.0pt;} @list l1:level7 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:147.0pt; text-indent:-21.0pt;} @list l1:level8 {mso-level-number-format:alpha-lower; mso-level-text:"%8\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:168.0pt; text-indent:-21.0pt;} @list l1:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:189.0pt; text-indent:-21.0pt;} @list l2 {mso-list-id:1693413572; mso-list-type:hybrid; mso-list-template-ids:2031769436 699536156 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} @list l2:level1 {mso-level-start-at:0; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:SimSun;} @list l2:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3 {mso-list-id:2051028364; mso-list-template-ids:-356333876;} @list l3:level1 {mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} -->
Thank you for making the video.

We three have some comments and questions on the video.

1) the style of the package view is not consistent with the one of recipe view.
True. I was planning to redesign the recipe view  and the package view to bring them in line with the Packages screen. I think I need to clarify the difference between windows and dialogues in the interface. In the design shown in the video, Hob has one window, which changes depending on the building stage to show one of the following screens: Image configuration, Building packages, Packages, Building image and Image details. The 'recipe view' and the 'package view' are dialogues that you launch via the 'view recipes' and 'view packages' buttons. Therefore, the Packages screen that displays after the packages are built, and the package dialogue you launch using the 'view packages' button, are 2 different things.

[Shane]: OK, I understand they are 2 difference screens. But actually both can reuse the same screen, because I didn't see any functional difference between the Packages screen and the Packages dialog.
[Dongxiao]: In case you are trying to re-design the recipe view and package view, some thoughts here
- package view and package screen actually are showing the same contents, can we merge them together? I mean if user clicks the package view, they are moved to the "Package" stage.
- Will recipe view and package view also be design to be "window" instead of screen?

In your previous video, recipe view has sort of "summary" which lists all recipes selected on the right side. Can we remove the tab "Included" and make a "summary" for the package view? And with the tab "Included", we need to scroll down to find a package or locate it in the search box, and then do "Remove" for example, it is not better than the "summary" because the "summary" can show all or more.

I agree that the Packages screen should look similar to the Recipes dialogue and the Packages dialogue. But after seeing the 'summary' working it seems to me that it is not the best solution. The goals of the summary were:

  1.  Allow users to easily see what's selected to be included in their image
  2.  Allow users to easily understand what's brought by what
I am not sure the existing summary does a good job at any of the two. Space restrictions make reading what's included quite difficult (particularly when the names of packages or recipes wrap), and the layout does not facilitate skimming content, which is what you'll do with the summary (you won't read it all from top to bottom: you'll skim the recipes/packages to find something you are looking for). The relationship between what brings what, represented by the highlight, is lost once you perform a new selection. The summary also creates a lot of clutter in the interface: the screen is so busy, it's hard to know what to look at.

[Shane]: I agree with you on "you won't read it all from top to bottom". But I found the summary had another advantage which "Included" in the current Packages screen doesn't have. That is: when I select one more package, what is brought by it will be highlighted, so I can see the difference between before and after I select.

The existing Packages screen presents less information at any given time: it feels cleaner and easier to read. It's true that it requires users to select the Included tab in order to see what's to be included in their image, but it provides a much more focused interface. The 'brought by' column avoids losing the relationship between what brings what, and the sorting and searching mechanisms should minimise the need for scrolling.

After multiple iterations (it took a very long time to design that screen), I believe the Included tab is a better solution than the Summary. If you are convinced that the Summary is better, we'll go for it, but I felt I had to explain my concerns with it.

[Shane]: Both have advantages and disadvantages. I don't think it is hard to implement "Included". On the contrary, the Summary is;-) I also like to hear some feedbacks from the community and the others.
BTW: do you mean in the Recipes dialog, we also replace the Summary with the tab "Included"?
2) ditto, I see there is a button "Build Image" in the package view. I know what the purpose is. But for the recipe view, there is no button. We also can "build image" or "build package" in the recipe view without going back to the main window at 1:39. Do you mind that we simplify by removing "Build Image" in the package view?
I think there is some confusion about the Packages screen (which is a window), and what you call the 'package view' and 'recipe view', which are dialogues. This is really my fault: I should have explained this better.
I've designed the Hob interface as a multi-step process with 3 steps, each represented by a screen displayed in the main Hob window:
Step 1 - Image configuration screen: users input the build parameters, such as machine, base image and recipes
Step 2 - Package screen: this is not a mandatory step. You can skip it by selecting 'Build image' in Step 1. Users review and might edit the list of packages to be included in their image, and then proceed to build the image. The 'Build image' button is required to proceed to Step 3
Step 3 - Image details screen: the image has been built, and users can select from a range of possible actions

[Shane]: I see. They are 2 different things.

Since the above screens are steps in a process, they require an action (i.e. a button) to move to the next step of the process.

The recipes and packages dialogues are not steps in the building process: they are contained pieces of functionality that can be displayed on demand. The recipes dialogue allows users to see and edit the recipes included in the base image. I assume the packages dialogue allows users to include already built packages in the base image (if this is not correct please let me know).

[Shane]: Your assumption is right.

The actions in any dialogue should be 'Save' and 'Cancel'. Those actions were not included in the original design because I didn't think of them as dialogues: more as inspectors like the ones in Gimp. You implemented them as dialogues, which I think works really well (probably better than as inspectors I must say): we just need to add those 'Save' and 'Cancel' buttons to them.

I hope this explains why we have a 'Build image' button in the Packages screen, but not in the recipes and packages dialogues.

[Shane]: Understand.

3) After clicking "My images" to open an image, how does UI determine to show "Run Image" or "Write to Storage", or "Deploy" or "View Image files"?

First of all, you are right: 'Deploy' and 'Write to storage' are exactly the same thing. I meant to use 'Write to storage' everywhere: sorry about that. My bad :(

- If the building output included a live image, the Image details screen shows the 'Write to storage' button
- If the image is a qemu image, the Image details screen shows the 'Run image' button. Clicking the button starts up the virtual machine

[Shane]: Makes sense. A technical question for expert in the mail list, how can we distinguish whether an image is a QEMU image or an image for real hardware, regarding the fact users can change the image name as they want?

- Otherwise the Image details screen shows the 'View image files' button

[Shane]: Can you give an example about "Otherwise"?

I hope this makes sense. Otherwise let me know.

[Dongxiao]: Does it make sense if a user opens a .tar.gz file in our GUI and then it jumps to the image information page? I think as a Linux user, I will not try to open any .tar.gz file by file chooser because in my straight understanding, those .tar.gz files may be large and opening them will cause a lot of time or may hang.

4) At 6:36, how can the user go back to the main window at 1:39? Should the user wait until the build is finished or stop it by clicking "Stop build"?
Exactly: the only option at that point is to stop the build. I haven't designed what happens when you stop the build yet, but I'd say something similar to what happens now: a prompt asks users to confirm that they want to stop the build, and if yes Hob reverts back to the screen from which the user started the building image process, which can be the Image configuration screen or the Packages screen.

[Shane]: Understand. If any error happens when building, it will stay there because I assume users want to see the log. Then how can users get back to the Image configuration screen or the Package screen, after closing it?
5) For "save template" and "load template", the only chance for users to do "save template" is when the build is done, yes?
Well, I don't know. That's the way it seems to work in the latest version of Hob, but it doesn't mean it has to stay that way.

However, we think users can save any settings for build environments, and any selection of packages or recipes in an image even though the build doesn't start. Then next time he/she can resume the job by starting with the stuffs saved.
I totally agree with you that users should be able to save a template before building the image.

Again, we are considering whether it is good to put "load template" and "save template" together, because they are similar actions.
I don't think I would do it that way. 'Load template' is a way to initiate the building process, and therefore something you might want to do at any time. As such, it makes sense to make it an option in the toolbar, like 'opening an image', where is always available.

'Save template' is something that sequentially comes after configuring the image parameters. It's like a function that takes as parameters a machine and a base image (with its recipes or packages). Therefore the action of saving a template only makes sense when a machine and base image have been selected. If you represent it as a button in the toolbar, you will have to show it in an inactive state until a machine and base image have been selected. Otherwise, what are you saving as a template? As such, it makes sense to display it after those parameters have been set, i.e., after the 'View recipes' and 'View packages' buttons.

If you agree with the above, I can review the Image configuration screen and add a 'Save as template' action to it.

[Shane]: OK, I agree to enable the button "Save as template" after all parameters in the Image configuration screen have been set. Keep this open, please.
6) At 7:07, "view files" is the same as "My images"?

I don't think so. 'My images' would open a File Chooser Dialog
http://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html
Selecting an image file from the file chooser dialog would open the Hob "Image details' screen for the selected image file.

"View files" would open a regular file manager window in the tmp/deploy/images directory. Selecting the image file from this file manager window would simply open the image in the default application assigned to the file extension (it would not open the image details screen in Hob). "View files" is just a quick way to navigate to the tmp/deploy/images directory.

[Shane]: OK, I see.
7) We are thinking "My images" is similar as "Load template", because the image contains the info of settings etc. so does the template. The only diff is after opening an image, we can deploy it or run it. But for template, it is sort of "virtual" stuff, we have to build according to the definitions of the template. So, to some extent, "My images" = "Template" + able to deploy and run, what do you think?
I agree, but I also think that the ability to deploy and run that comes with images and is missing from templates is a significant difference. It means that the logical next steps after opening a template and opening an image are very different too.
After opening a template the logical next steps are: edit the parameters if you wish, then build. That's why loading a template brings you to the Image configuration screen, where you can edit parameters and build.

After opening an image the logical next steps are deploy / run. That's why opening an image brings you to the Image details screen, where you can deploy / run.
[Shane]: But on the Image details screen, you can click "Edit Configuration" to go to the Image configuration screen. Then the rest is totally the same as the above.
A technical question comes to me, it is also for experts. Is there a way to modify bitbake to write some more information into the target image, and for Hob to unpack and fetch the information later?
For this part, we also consider the client/server mode with XMLRPC: We have the capability to run bitbake server on the server side, but UI on the client side. So the image in "My images" always is generated on the server side, and the template in "Load template" is a config file on the client side.
It sort of makes sense to me that templates are local files, while images are kept on a server where they can be shared, but I definitely don't know enough to have an opinion. You guys are the experts on this! :)
I guess that if no client / server mode is set up and I am running everything locally, then images will also be kept locally. Is that the case?

[Shane]: Yes, that is. Temporarily we can skip the case running on client and server. We assume all are on the client.
8) We already saw some buttons "Settings", "Deploy image", "Run image", "Load Template" and "Save Template", "Build New image", "Edit Configuration" or "Edit packages", "View image files" on different windows. So probably that makes switching between windows a bit complex. For instance, At 8:24, clicking "Edit packages" will go back to the package view. But what if users just make a mistake on the UI and want to go back to the window at 8:24?
Well, they can't :) The Packages screen is an intermediate step that allows you to view and edit the packages to be included in your image: nothing else. If you land there by mistake, you can still get out via the 'Back to image configuration' option. From there, you can go back to the Image configuration screen by opening the image you built.

We could change the "Build image" button into a go forward button, and if the user makes any changes to the packages display again the 'Build image' button, but I am not sure if it would be worth the development effort.

Providing access to all previous screens could be done by some kind of breadcrumb (a representation of each step in the process you can click on to access the step), but breadcrumbs are problematic when the number of steps in a process can change, like in Hob. Remember than you can decide to go through the packages step, or skip it and build the image directly.

[Shane]: Personally, I don't like to change "Build image" to a "Go forward" button, because it would be possible that users want to rebuild the image without any change.
With many buttons on many windows, we have a lot of combinations, then we have a lot of states for the UI.

True: there are a few things you can do in the Image details screen. You can save your image as a template, you can edit the image, you can view the image files,  you can deploy or run the image when applicable, and you can build a new image. You can also open a Template or a different image. All those are reasonable next steps once you have reached the end of building process, and all of them should be present in the interface.
And we are thinking "Settings", "Deploy image", "Run image", "Load Template" and "Save Template" are important for us, and whether we can use menus or buttons on a toolbar. We prefer the latter, and prefer we have a main window and others are all dialogs inherited from the main window. What do you think on this?
I can see your point here. I did consider that structure after I saw it working. It's quite nice. However, I can see a couple of problems with it:

  1.  It brings the concept of progressive disclosure (new options displaying as a result of user selections) that we use in the Image configuration screen to a breaking point. There are too many things happening in that main window. When you start building, the progress bar has to display at the bottom of the screen, which looks awkward, and there is not enough space to provide clear next steps after the packages and image have been built.
  2.  Having 'Deploy image' and 'Run image' buttons in the toolbar will cause problems. They fire actions that require a parameter (an image to deploy or run). They could get this parameter by taking the last image that has been built, and deploy or run that image. But what if no image has been built yet? What if the last image was built a few days ago and it's not at all the image you want to deploy or run? The alternative would be asking the user what's the image she wants to deploy or run. You would open a file chooser dialog for that. But imagine the following situation: I've just finished building a qemu image. The "congratulations" message and the path to my image are displayed at the bottom of the main screen. I want to run my image, so I click on the 'run image' button in the toolbar, expecting it of course to run the qemu image I've just built. Instead, it pops up a file chooser dialog and I have to select the image I just built to run it! Such a system would feel a bit dumb: why is it asking me which image do I want to run? Isn't it obvious I want to run the qemu image I've just built? To avoid this type of 'dumb' reactions by the UI, actions should be displayed where and when applicable. Actions in toolbars and menus are always present, which means they are always applicable, they make sense at all times, independently of the system state: I call them global actions. Opening a template, opening an image or accessing settings are kind of global actions. Running or deploying an image are 'contextual' actions, they only make sense when the system is in a certain state: for example, right after building a qemu image. If you position global actions in toolbars or menus, you will have to make extensive use of inactive states, which means displaying things that don't make sense in such a way that you cannot use them (which is just noise), or make them behave in different ways depending on the system state (which is confusing).
[Dongxiao]: Hob can have the functionality that, even if user didn't build an image at this time, it could still be used as a deploy tool to burn previous built images to usb disks, or run those pre-built images by QEMU. What about designing to buttons, one is "Burn Lastest Built Image" and "Burn Previous Built Image"? (Ignore my poor button name)
9) a small question as Dave has, what is the diff between "deploy image"and "write to storage"? We think they are the same.
Dave is completely right: 'Deploy' and 'Write to storage' are exactly the same thing. I meant to use 'Write to storage' everywhere: sorry about that. My bad :(

[Shane]: Three more we want to consider:
1. we want to add proxy setting into "Settings" to support proxy
2. When users fail to build images, there is no option or button to clean all (like sstate) but bitbake command has (bitbake -c cleanall). We hope to add it into the GUI.
3. can the button "Settings" be there only on the Image configuration screen? It doesn't make any sense to set the parameters on the Image details screen, agree?
    Ditto for "Load Template" on the Image details screen. We also can initiate a new build by "Build new image" and "Load Template", thoughts?
Sorry, many feedbacks;-) And we are also thinking to simplify the rest of the design and finalize asap so we can finish the implementation before the end of M3. (the end of Feb).

I totally understand you might not have time to implement the design I've sent. If this is the problem, please do let me know, and let's talk about what's feasible. Maybe we could keep the current structure (all steps in the main screen), but look for some alternative options to position the 'Deploy image', 'Run image' and 'Save as template' actions ... not in the toolbar or menus, please! ;)

[Shane]: We will try our best.
Another FYI, we get your feedbacks in the two pdf files you sent previously and are revising the UI.

Thanks.

[-- Attachment #2: Type: text/html, Size: 69551 bytes --]

Re: RFC: Hob 1.2 design

[Wang, Shane]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

I get one more:

In the Image details screen, after opening an image file by clicking "My images", we don't allow to "Edit Package", I think.
Because with an image only, we can't generate the packages from it, you can't assume there is a build directory (tmp/), is my understanding correct?

--
Shane

[-- Attachment #2: Type: text/html, Size: 8717 bytes --]

Re: RFC: Hob 1.2 design

[Joshua Lock]

Some thoughts inline, I've snipped out text unrelated to my comments.

On 02/02/12 04:48, Wang, Shane wrote:
> In your previous video, recipe view has sort of “summary” which lists
> all recipes selected on the right side. Can we remove the tab “Included”
> and make a “summary” for the package view? And with the tab “Included”,
> we need to scroll down to find a package or locate it in the search box,
> and then do “Remove” for example, it is not better than the “summary”
> because the “summary” can show all or more.
>
> I agree that the Packages screen should look similar to the Recipes
> dialogue and the Packages dialogue. But after seeing the 'summary'
> working it seems to me that it is not the best solution. The goals of
> the summary were:
>
>  1. Allow users to easily see what's selected to be included in their image
>  2. Allow users to easily understand what's brought by what
>
> I am not sure the existing summary does a good job at any of the two.
> Space restrictions make reading what's included quite difficult
> (particularly when the names of packages or recipes wrap), and the
> layout does not facilitate skimming content, which is what you'll do
> with the summary (you won't read it all from top to bottom: you'll skim
> the recipes/packages to find something you are looking for). The
> relationship between what brings what, represented by the highlight, is
> lost once you perform a new selection. The summary also creates a lot of
> clutter in the interface: the screen is so busy, it's hard to know what
> to look at.
>
> [Shane]: I agree with you on “you won't read it all from top to bottom”.
> But I found the summary had another advantage which “Included” in the
> current Packages screen doesn’t have. That is: when I select one more
> package, what is brought by it will be highlighted, so I can see the
> difference between before and after I select.
>
> The existing Packages screen presents less information at any given
> time: it feels cleaner and easier to read. It's true that it requires
> users to select the Included tab in order to see what's to be included
> in their image, but it provides a much more focused interface. The
> 'brought by' column avoids losing the relationship between what brings
> what, and the sorting and searching mechanisms should minimise the need
> for scrolling.
>
> After multiple iterations (it took a very long time to design that
> screen), I believe the Included tab is a better solution than the
> Summary. If you are convinced that the Summary is better, we'll go for
> it, but I felt I had to explain my concerns with it.

One idea is that we could offer filters on the list, so that the user 
can click the "included" filter and only the packages selected for 
inclusion will be shown - this suggestion is inspired by Thunderbirds 
mail view which can be filtered on unread, starred, etc.

> 3) After clicking “My images” to open an image, how does UI determine to
> show “Run Image” or “Write to Storage”, or “Deploy” or “View Image files”?
>
> First of all, you are right: 'Deploy' and 'Write to storage' are exactly
> the same thing. I meant to use 'Write to storage' everywhere: sorry
> about that. My bad :(
>
> - If the building output included a live image, the Image details screen
> shows the 'Write to storage' button
>
> - If the image is a qemu image, the Image details screen shows the 'Run
> image' button. Clicking the button starts up the virtual machine
>
> [Shane]: Makes sense. A technical question for expert in the mail list,
> how can we distinguish whether an image is a QEMU image or an image for
> real hardware, regarding the fact users can change the image name as
> they want?

I don't know of a way to do this, though someone else may suggest one.
A way we could provide such functionality within Hob might be to set a 
filesystem extended attribute on the files of which MACHINE they were 
build for. Then Hob can read this attribute back and if it's not set 
assume it's not a qemu image. Thoughts?

> 5) For “save template” and “load template”, the only chance for users to
> do “save template” is when the build is done, yes?
>
> Well, I don't know. That's the way it seems to work in the latest
> version of Hob, but it doesn't mean it has to stay that way.

Hmm, really? That's more by oversight than by design ;-)

> A technical question comes to me, it is also for experts. Is there a way
> to modify bitbake to write some more information into the target image,
> and for Hob to unpack and fetch the information later?

Once again, I don't know of a current way but could suggest Extended 
Attributes as one option.

Finally, whilst discussing this in the office Darren raised a concern 
about restricting the 'launch in emulator' option to only images built 
for the qemu machine types citing his use of qemu with FRI2 images.

He suggested: "For images with an ext[234] or other FS image suitable 
for qemu, present the "launch in qemu" button. For images that have the 
hddimg extension, present the Burn to Disk option."

Cheers,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: RFC: Hob 1.2 design

[Wang, Shane]

[-- Attachment #1: Type: text/plain, Size: 25539 bytes --]

Please see my feedbacks embedded in red.

Thanks.
--
Shane
From: "Wang, Shane" <shane.wang@intel.com<mailto:shane.wang@intel.com>>
Date: Wed, 1 Feb 2012 14:49:38 +0000
To: "Belen Barros Pena (Intel)" <belen.barros.pena@intel.com<mailto:belen.barros.pena@intel.com>>, "Xu, Dongxiao" <dongxiao.xu@intel.com<mailto:dongxiao.xu@intel.com>>, "Lu, Lianhao" <lianhao.lu@intel.com<mailto:lianhao.lu@intel.com>>
Subject: RE: Hob 1.2 next steps

<!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Times New Roman","serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin:0cm; margin-bottom:.0001pt; text-indent:21.0pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:SimSun;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal; font-family:"Courier New"; color:blue; font-weight:normal; font-style:normal; text-decoration:none none;} span.EmailStyle22 {mso-style-type:personal; font-family:"Courier New"; color:blue; font-weight:normal; font-style:normal; text-decoration:none none;} span.EmailStyle23 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1335497491; mso-list-template-ids:-608031632;} @list l1 {mso-list-id:1405881917; mso-list-type:hybrid; mso-list-template-ids:-2065393162 -1271618664 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} @list l1:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt;} @list l1:level2 {mso-level-number-format:alpha-lower; mso-level-text:"%2\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:42.0pt; text-indent:-21.0pt;} @list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:63.0pt; text-indent:-21.0pt;} @list l1:level4 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:84.0pt; text-indent:-21.0pt;} @list l1:level5 {mso-level-number-format:alpha-lower; mso-level-text:"%5\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:105.0pt; text-indent:-21.0pt;} @list l1:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:126.0pt; text-indent:-21.0pt;} @list l1:level7 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:147.0pt; text-indent:-21.0pt;} @list l1:level8 {mso-level-number-format:alpha-lower; mso-level-text:"%8\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:168.0pt; text-indent:-21.0pt;} @list l1:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:189.0pt; text-indent:-21.0pt;} @list l2 {mso-list-id:1693413572; mso-list-type:hybrid; mso-list-template-ids:2031769436 699536156 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} @list l2:level1 {mso-level-start-at:0; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt; font-family:"Calibri","sans-serif"; mso-fareast-font-family:SimSun;} @list l2:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3 {mso-list-id:2051028364; mso-list-template-ids:-356333876;} @list l3:level1 {mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level2 {mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level3 {mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level5 {mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level6 {mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level7 {mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level8 {mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} -->
Thank you for making the video.

We three have some comments and questions on the video.

1) the style of the package view is not consistent with the one of recipe view.
True. I was planning to redesign the recipe view  and the package view to bring them in line with the Packages screen. I think I need to clarify the difference between windows and dialogues in the interface. In the design shown in the video, Hob has one window, which changes depending on the building stage to show one of the following screens: Image configuration, Building packages, Packages, Building image and Image details. The 'recipe view' and the 'package view' are dialogues that you launch via the 'view recipes' and 'view packages' buttons. Therefore, the Packages screen that displays after the packages are built, and the package dialogue you launch using the 'view packages' button, are 2 different things.

[Shane]: OK, I understand they are 2 difference screens. But actually both can reuse the same screen, because I didn't see any functional difference between the Packages screen and the Packages dialog.

In your previous video, recipe view has sort of "summary" which lists all recipes selected on the right side. Can we remove the tab "Included" and make a "summary" for the package view? And with the tab "Included", we need to scroll down to find a package or locate it in the search box, and then do "Remove" for example, it is not better than the "summary" because the "summary" can show all or more.

I agree that the Packages screen should look similar to the Recipes dialogue and the Packages dialogue. But after seeing the 'summary' working it seems to me that it is not the best solution. The goals of the summary were:

  1.  Allow users to easily see what's selected to be included in their image
  2.  Allow users to easily understand what's brought by what
I am not sure the existing summary does a good job at any of the two. Space restrictions make reading what's included quite difficult (particularly when the names of packages or recipes wrap), and the layout does not facilitate skimming content, which is what you'll do with the summary (you won't read it all from top to bottom: you'll skim the recipes/packages to find something you are looking for). The relationship between what brings what, represented by the highlight, is lost once you perform a new selection. The summary also creates a lot of clutter in the interface: the screen is so busy, it's hard to know what to look at.

[Shane]: I agree with you on "you won't read it all from top to bottom". But I found the summary had another advantage which "Included" in the current Packages screen doesn't have. That is: when I select one more package, what is brought by it will be highlighted, so I can see the difference between before and after I select.

The existing Packages screen presents less information at any given time: it feels cleaner and easier to read. It's true that it requires users to select the Included tab in order to see what's to be included in their image, but it provides a much more focused interface. The 'brought by' column avoids losing the relationship between what brings what, and the sorting and searching mechanisms should minimise the need for scrolling.

After multiple iterations (it took a very long time to design that screen), I believe the Included tab is a better solution than the Summary. If you are convinced that the Summary is better, we'll go for it, but I felt I had to explain my concerns with it.

[Shane]: Both have advantages and disadvantages. I don't think it is hard to implement "Included". On the contrary, the Summary is;-) I also like to hear some feedbacks from the community and the others.
BTW: do you mean in the Recipes dialog, we also replace the Summary with the tab "Included"?
2) ditto, I see there is a button "Build Image" in the package view. I know what the purpose is. But for the recipe view, there is no button. We also can "build image" or "build package" in the recipe view without going back to the main window at 1:39. Do you mind that we simplify by removing "Build Image" in the package view?
I think there is some confusion about the Packages screen (which is a window), and what you call the 'package view' and 'recipe view', which are dialogues. This is really my fault: I should have explained this better.
I've designed the Hob interface as a multi-step process with 3 steps, each represented by a screen displayed in the main Hob window:
Step 1 - Image configuration screen: users input the build parameters, such as machine, base image and recipes
Step 2 - Package screen: this is not a mandatory step. You can skip it by selecting 'Build image' in Step 1. Users review and might edit the list of packages to be included in their image, and then proceed to build the image. The 'Build image' button is required to proceed to Step 3
Step 3 - Image details screen: the image has been built, and users can select from a range of possible actions

[Shane]: I see. They are 2 different things.

Since the above screens are steps in a process, they require an action (i.e. a button) to move to the next step of the process.

The recipes and packages dialogues are not steps in the building process: they are contained pieces of functionality that can be displayed on demand. The recipes dialogue allows users to see and edit the recipes included in the base image. I assume the packages dialogue allows users to include already built packages in the base image (if this is not correct please let me know).

[Shane]: Your assumption is right.

The actions in any dialogue should be 'Save' and 'Cancel'. Those actions were not included in the original design because I didn't think of them as dialogues: more as inspectors like the ones in Gimp. You implemented them as dialogues, which I think works really well (probably better than as inspectors I must say): we just need to add those 'Save' and 'Cancel' buttons to them.

I hope this explains why we have a 'Build image' button in the Packages screen, but not in the recipes and packages dialogues.

[Shane]: Understand.

3) After clicking "My images" to open an image, how does UI determine to show "Run Image" or "Write to Storage", or "Deploy" or "View Image files"?

First of all, you are right: 'Deploy' and 'Write to storage' are exactly the same thing. I meant to use 'Write to storage' everywhere: sorry about that. My bad :(

- If the building output included a live image, the Image details screen shows the 'Write to storage' button
- If the image is a qemu image, the Image details screen shows the 'Run image' button. Clicking the button starts up the virtual machine

[Shane]: Makes sense. A technical question for expert in the mail list, how can we distinguish whether an image is a QEMU image or an image for real hardware, regarding the fact users can change the image name as they want?

- Otherwise the Image details screen shows the 'View image files' button

[Shane]: Can you give an example about "Otherwise"?

I hope this makes sense. Otherwise let me know.

4) At 6:36, how can the user go back to the main window at 1:39? Should the user wait until the build is finished or stop it by clicking "Stop build"?
Exactly: the only option at that point is to stop the build. I haven't designed what happens when you stop the build yet, but I'd say something similar to what happens now: a prompt asks users to confirm that they want to stop the build, and if yes Hob reverts back to the screen from which the user started the building image process, which can be the Image configuration screen or the Packages screen.

[Shane]: Understand. If any error happens when building, it will stay there because I assume users want to see the log. Then how can users get back to the Image configuration screen or the Package screen, after closing it?
5) For "save template" and "load template", the only chance for users to do "save template" is when the build is done, yes?
Well, I don't know. That's the way it seems to work in the latest version of Hob, but it doesn't mean it has to stay that way.

However, we think users can save any settings for build environments, and any selection of packages or recipes in an image even though the build doesn't start. Then next time he/she can resume the job by starting with the stuffs saved.
I totally agree with you that users should be able to save a template before building the image.

Again, we are considering whether it is good to put "load template" and "save template" together, because they are similar actions.
I don't think I would do it that way. 'Load template' is a way to initiate the building process, and therefore something you might want to do at any time. As such, it makes sense to make it an option in the toolbar, like 'opening an image', where is always available.

'Save template' is something that sequentially comes after configuring the image parameters. It's like a function that takes as parameters a machine and a base image (with its recipes or packages). Therefore the action of saving a template only makes sense when a machine and base image have been selected. If you represent it as a button in the toolbar, you will have to show it in an inactive state until a machine and base image have been selected. Otherwise, what are you saving as a template? As such, it makes sense to display it after those parameters have been set, i.e., after the 'View recipes' and 'View packages' buttons.

If you agree with the above, I can review the Image configuration screen and add a 'Save as template' action to it.

[Shane]: OK, I agree to enable the button "Save as template" after all parameters in the Image configuration screen have been set. Keep this open, please.
6) At 7:07, "view files" is the same as "My images"?

I don't think so. 'My images' would open a File Chooser Dialog
http://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html
Selecting an image file from the file chooser dialog would open the Hob "Image details' screen for the selected image file.

"View files" would open a regular file manager window in the tmp/deploy/images directory. Selecting the image file from this file manager window would simply open the image in the default application assigned to the file extension (it would not open the image details screen in Hob). "View files" is just a quick way to navigate to the tmp/deploy/images directory.

[Shane]: OK, I see.
7) We are thinking "My images" is similar as "Load template", because the image contains the info of settings etc. so does the template. The only diff is after opening an image, we can deploy it or run it. But for template, it is sort of "virtual" stuff, we have to build according to the definitions of the template. So, to some extent, "My images" = "Template" + able to deploy and run, what do you think?
I agree, but I also think that the ability to deploy and run that comes with images and is missing from templates is a significant difference. It means that the logical next steps after opening a template and opening an image are very different too.
After opening a template the logical next steps are: edit the parameters if you wish, then build. That's why loading a template brings you to the Image configuration screen, where you can edit parameters and build.

After opening an image the logical next steps are deploy / run. That's why opening an image brings you to the Image details screen, where you can deploy / run.
[Shane]: But on the Image details screen, you can click "Edit Configuration" to go to the Image configuration screen. Then the rest is totally the same as the above.
A technical question comes to me, it is also for experts. Is there a way to modify bitbake to write some more information into the target image, and for Hob to unpack and fetch the information later?
For this part, we also consider the client/server mode with XMLRPC: We have the capability to run bitbake server on the server side, but UI on the client side. So the image in "My images" always is generated on the server side, and the template in "Load template" is a config file on the client side.
It sort of makes sense to me that templates are local files, while images are kept on a server where they can be shared, but I definitely don't know enough to have an opinion. You guys are the experts on this! :)
I guess that if no client / server mode is set up and I am running everything locally, then images will also be kept locally. Is that the case?

[Shane]: Yes, that is. Temporarily we can skip the case running on client and server. We assume all are on the client.
8) We already saw some buttons "Settings", "Deploy image", "Run image", "Load Template" and "Save Template", "Build New image", "Edit Configuration" or "Edit packages", "View image files" on different windows. So probably that makes switching between windows a bit complex. For instance, At 8:24, clicking "Edit packages" will go back to the package view. But what if users just make a mistake on the UI and want to go back to the window at 8:24?
Well, they can't :) The Packages screen is an intermediate step that allows you to view and edit the packages to be included in your image: nothing else. If you land there by mistake, you can still get out via the 'Back to image configuration' option. From there, you can go back to the Image configuration screen by opening the image you built.

We could change the "Build image" button into a go forward button, and if the user makes any changes to the packages display again the 'Build image' button, but I am not sure if it would be worth the development effort.

Providing access to all previous screens could be done by some kind of breadcrumb (a representation of each step in the process you can click on to access the step), but breadcrumbs are problematic when the number of steps in a process can change, like in Hob. Remember than you can decide to go through the packages step, or skip it and build the image directly.

[Shane]: Personally, I don't like to change "Build image" to a "Go forward" button, because it would be possible that users want to rebuild the image without any change.
With many buttons on many windows, we have a lot of combinations, then we have a lot of states for the UI.

True: there are a few things you can do in the Image details screen. You can save your image as a template, you can edit the image, you can view the image files,  you can deploy or run the image when applicable, and you can build a new image. You can also open a Template or a different image. All those are reasonable next steps once you have reached the end of building process, and all of them should be present in the interface.
And we are thinking "Settings", "Deploy image", "Run image", "Load Template" and "Save Template" are important for us, and whether we can use menus or buttons on a toolbar. We prefer the latter, and prefer we have a main window and others are all dialogs inherited from the main window. What do you think on this?
I can see your point here. I did consider that structure after I saw it working. It's quite nice. However, I can see a couple of problems with it:

  1.  It brings the concept of progressive disclosure (new options displaying as a result of user selections) that we use in the Image configuration screen to a breaking point. There are too many things happening in that main window. When you start building, the progress bar has to display at the bottom of the screen, which looks awkward, and there is not enough space to provide clear next steps after the packages and image have been built.
  2.  Having 'Deploy image' and 'Run image' buttons in the toolbar will cause problems. They fire actions that require a parameter (an image to deploy or run). They could get this parameter by taking the last image that has been built, and deploy or run that image. But what if no image has been built yet? What if the last image was built a few days ago and it's not at all the image you want to deploy or run? The alternative would be asking the user what's the image she wants to deploy or run. You would open a file chooser dialog for that. But imagine the following situation: I've just finished building a qemu image. The "congratulations" message and the path to my image are displayed at the bottom of the main screen. I want to run my image, so I click on the 'run image' button in the toolbar, expecting it of course to run the qemu image I've just built. Instead, it pops up a file chooser dialog and I have to select the image I just built to run it! Such a system would feel a bit dumb: why is it asking me which image do I want to run? Isn't it obvious I want to run the qemu image I've just built? To avoid this type of 'dumb' reactions by the UI, actions should be displayed where and when applicable. Actions in toolbars and menus are always present, which means they are always applicable, they make sense at all times, independently of the system state: I call them global actions. Opening a template, opening an image or accessing settings are kind of global actions. Running or deploying an image are 'contextual' actions, they only make sense when the system is in a certain state: for example, right after building a qemu image. If you position global actions in toolbars or menus, you will have to make extensive use of inactive states, which means displaying things that don't make sense in such a way that you cannot use them (which is just noise), or make them behave in different ways depending on the system state (which is confusing).
9) a small question as Dave has, what is the diff between "deploy image"and "write to storage"? We think they are the same.
Dave is completely right: 'Deploy' and 'Write to storage' are exactly the same thing. I meant to use 'Write to storage' everywhere: sorry about that. My bad :(

[Shane]: Three more we want to consider:
1. we want to add proxy setting into "Settings" to support proxy
2. When users fail to build images, there is no option or button to clean all (like sstate) but bitbake command has (bitbake -c cleanall). We hope to add it into the GUI.
3. can the button "Settings" be there only on the Image configuration screen? It doesn't make any sense to set the parameters on the Image details screen, agree?
    Ditto for "Load Template" on the Image details screen. We also can initiate a new build by "Build new image" and "Load Template", thoughts?
Sorry, many feedbacks;-) And we are also thinking to simplify the rest of the design and finalize asap so we can finish the implementation before the end of M3. (the end of Feb).

I totally understand you might not have time to implement the design I've sent. If this is the problem, please do let me know, and let's talk about what's feasible. Maybe we could keep the current structure (all steps in the main screen), but look for some alternative options to position the 'Deploy image', 'Run image' and 'Save as template' actions ... not in the toolbar or menus, please! ;)

[Shane]: We will try our best.
Another FYI, we get your feedbacks in the two pdf files you sent previously and are revising the UI.

Thanks.

[-- Attachment #2: Type: text/html, Size: 67639 bytes --]