Please see my feedbacks embedded in red.
Thanks.
--
Shane
From:
"Wang, Shane" <shane.wang@intel.com>
Date: Wed, 1 Feb 2012 14:49:38 +0000
To: "Belen Barros Pena (Intel)" <belen.barros.pena@intel.com>,
"Xu, Dongxiao" <dongxiao.xu@intel.com>,
"Lu, Lianhao" <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:
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
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:
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.