[yocto] RFC: Hob 1.2 design

Thu Feb 2 16:35:17 PST 2012

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 at yoctoproject.org
Subject: Re: RFC: Hob 1.2 design

Please see my feedbacks embedded in red.

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20120203/f6e24e90/attachment.html>