From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B9F05E0059B for ; Thu, 2 Feb 2012 04:48:47 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 02 Feb 2012 04:48:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="119645332" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga002.fm.intel.com with ESMTP; 02 Feb 2012 04:48:45 -0800 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 2 Feb 2012 20:48:06 +0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Feb 2012 20:48:05 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id 14.01.0355.002; Thu, 2 Feb 2012 20:48:04 +0800 From: "Wang, Shane" To: "Wang, Shane" , "Barros Pena, Belen" , "Xu, Dongxiao" , "Lu, Lianhao" Thread-Topic: RFC: Hob 1.2 design Thread-Index: AQHM1ghN2ta+vDnY0kiXcbK0irRQ85YS108ggAGuLCCAAHlrgIAGmYWAgAb8MNCAAqn0gIACotQAgABGdBCAAFS8AIAAmk2AgABm6zA= Date: Thu, 2 Feb 2012 12:48:03 +0000 Message-ID: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> References: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9F5F@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "Purdie, Richard" , "Lock, Joshua" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 12:48:48 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255SHSMSX102ccrcor_" --_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255SHSMSX102ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see my feedbacks embedded in red. Thanks. -- Shane From: "Wang, Shane" > Date: Wed, 1 Feb 2012 14:49:38 +0000 To: "Belen Barros Pena (Intel)" >, "Xu, Dongxiao" >, "Lu, Lianhao" > 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 v= iew. True. I was planning to redesign the recipe view and the package view to b= ring them in line with the Packages screen. I think I need to clarify the d= ifference between windows and dialogues in the interface. In the design sho= wn in the video, Hob has one window, which changes depending on the buildin= g stage to show one of the following screens: Image configuration, Building= packages, Packages, Building image and Image details. The 'recipe view' an= d the 'package view' are dialogues that you launch via the 'view recipes' a= nd 'view packages' buttons. Therefore, the Packages screen that displays af= ter 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 b= etween the Packages screen and the Packages dialog. In your previous video, recipe view has sort of "summary" which lists all r= ecipes selected on the right side. Can we remove the tab "Included" and mak= e 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 "summ= ary" can show all or more. I agree that the Packages screen should look similar to the Recipes dialogu= e and the Packages dialogue. But after seeing the 'summary' working it seem= s 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 ima= ge 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 wh= en the names of packages or recipes wrap), and the layout does not facilita= te skimming content, which is what you'll do with the summary (you won't re= ad it all from top to bottom: you'll skim the recipes/packages to find some= thing you are looking for). The relationship between what brings what, repr= esented by the highlight, is lost once you perform a new selection. The sum= mary 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". Bu= t 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, wha= t 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: i= t feels cleaner and easier to read. It's true that it requires users to sel= ect 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 avoi= ds losing the relationship between what brings what, and the sorting and se= arching 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 a= re 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 t= o implement "Included". On the contrary, the Summary is;-) I also like to h= ear some feedbacks from the community and the others. BTW: do you mean in the Recipes dialog, we also replace the Summary with th= e 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 windo= w), and what you call the 'package view' and 'recipe view', which are dialo= gues. 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 s= electing 'Build image' in Step 1. Users review and might edit the list of p= ackages 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 sele= ct 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: t= hey are contained pieces of functionality that can be displayed on demand. = The recipes dialogue allows users to see and edit the recipes included in t= he base image. I assume the packages dialogue allows users to include alrea= dy built packages in the base image (if this is not correct please let me k= now). [Shane]: Your assumption is right. The actions in any dialogue should be 'Save' and 'Cancel'. Those actions we= re not included in the original design because I didn't think of them as di= alogues: more as inspectors like the ones in Gimp. You implemented them as = dialogues, which I think works really well (probably better than as inspect= ors I must say): we just need to add those 'Save' and 'Cancel' buttons to t= hem. I hope this explains why we have a 'Build image' button in the Packages scr= een, but not in the recipes and packages dialogues. [Shane]: Understand. 3) After clicking "My images" to open an image, how does UI determine to sh= ow "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 th= e same thing. I meant to use 'Write to storage' everywhere: sorry about tha= t. My bad :( - If the building output included a live image, the Image details screen sh= ows the 'Write to storage' button - If the image is a qemu image, the Image details screen shows the 'Run ima= ge' 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 h= ardware, 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 desi= gned what happens when you stop the build yet, but I'd say something simila= r to what happens now: a prompt asks users to confirm that they want to sto= p 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 sc= reen 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 o= f Hob, but it doesn't mean it has to stay that way. However, we think users can save any settings for build environments, and a= ny 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 stu= ffs saved. I totally agree with you that users should be able to save a template befor= e building the image. Again, we are considering whether it is good to put "load template" and "sa= ve 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 t= ime. As such, it makes sense to make it an option in the toolbar, like 'ope= ning 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 a= nd a base image (with its recipes or packages). Therefore the action of sav= ing a template only makes sense when a machine and base image have been sel= ected. If you represent it as a button in the toolbar, you will have to sho= w 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 reci= pes' and 'View packages' buttons. If you agree with the above, I can review the Image configuration screen an= d add a 'Save as template' action to it. [Shane]: OK, I agree to enable the button "Save as template" after all para= meters in the Image configuration screen have been set. Keep this open, ple= ase. 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 "Im= age details' screen for the selected image file. "View files" would open a regular file manager window in the tmp/deploy/ima= ges directory. Selecting the image file from this file manager window would= simply open the image in the default application assigned to the file exte= nsion (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 i= mage 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, i= t is sort of "virtual" stuff, we have to build according to the definitions= of the template. So, to some extent, "My images" =3D "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 wit= h images and is missing from templates is a significant difference. It mean= s 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 Imag= e 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 depl= oy / 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 sam= e 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 f= or 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 cli= ent side. So the image in "My images" always is generated on the server sid= e, 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 a= re kept on a server where they can be shared, but I definitely don't know e= nough 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 everythi= ng 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 a= nd server. We assume all are on the client. 8) We already saw some buttons "Settings", "Deploy image", "Run image", "Lo= ad Template" and "Save Template", "Build New image", "Edit Configuration" o= r "Edit packages", "View image files" on different windows. So probably tha= t makes switching between windows a bit complex. For instance, At 8:24, cli= cking "Edit packages" will go back to the package view. But what if users j= ust 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 el= se. If you land there by mistake, you can still get out via the 'Back to im= age configuration' option. From there, you can go back to the Image configu= ration screen by opening the image you built. We could change the "Build image" button into a go forward button, and if t= he user makes any changes to the packages display again the 'Build image' b= utton, 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 brea= dcrumb (a representation of each step in the process you can click on to ac= cess 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 thro= ugh 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 h= ave a lot of states for the UI. True: there are a few things you can do in the Image details screen. You ca= n save your image as a template, you can edit the image, you can view the i= mage files, you can deploy or run the image when applicable, and you can b= uild a new image. You can also open a Template or a different image. All th= ose are reasonable next steps once you have reached the end of building pro= cess, 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 wind= ow and others are all dialogs inherited from the main window. What do you t= hink on this? I can see your point here. I did consider that structure after I saw it wor= king. It's quite nice. However, I can see a couple of problems with it: 1. It brings the concept of progressive disclosure (new options displayi= ng as a result of user selections) that we use in the Image configuration s= creen 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 bo= ttom of the screen, which looks awkward, and there is not enough space to p= rovide clear next steps after the packages and image have been built. 2. Having 'Deploy image' and 'Run image' buttons in the toolbar will cau= se 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 b= een built, and deploy or run that image. But what if no image has been buil= t 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 us= er what's the image she wants to deploy or run. You would open a file choos= er dialog for that. But imagine the following situation: I've just finished= building a qemu image. The "congratulations" message and the path to my im= age 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 cours= e 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 syste= m 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 thi= s type of 'dumb' reactions by the UI, actions should be displayed where and= when applicable. Actions in toolbars and menus are always present, which m= eans they are always applicable, they make sense at all times, independentl= y of the system state: I call them global actions. Opening a template, open= ing an image or accessing settings are kind of global actions. Running or d= eploying an image are 'contextual' actions, they only make sense when the s= ystem 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 mak= e 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 s= ame 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 a= ll (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 scree= n? It doesn't make any sense to set the parameters on the Image details scr= een, agree? Ditto for "Load Template" on the Image details screen. We also can init= iate a new build by "Build new image" and "Load Template", thoughts? Sorry, many feedbacks;-) And we are also thinking to simplify the rest of t= he 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 s= ent. If this is the problem, please do let me know, and let's talk about wh= at'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. --_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255SHSMSX102ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see my feedbacks emb= edded in red.

 

Thanks.

--

Shane

From: "Wang, Shane" <<= span style=3D"font-size:12.0pt">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" <l= ianhao.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-fac= e {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-fam= ily:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNor= mal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Ti= mes New Roman","serif";} a:link, span.MsoHyperlink {mso-styl= e-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoH= yperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {m= so-style-priority:99; mso-style-link:"Balloon Text Char"; margin:= 0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Times New Ro= man","serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin:0cm; margin-bottom:.00= 01pt; text-indent:21.0pt; font-size:12.0pt; font-family:"Times New Rom= an","serif";} span.BalloonTextChar {mso-style-name:"Bal= loon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:SimSun;} span.EmailStyle20 {mso-style-type:persona= l; font-family:"Calibri","sans-serif"; color:#1F497D;} = span.EmailStyle21 {mso-style-type:personal; font-family:"Courier New&q= uot;; color:blue; font-weight:normal; font-style:normal; text-decoration:no= ne none;} span.EmailStyle22 {mso-style-type:personal; font-family:"Couri= er New"; color:blue; font-weight:normal; font-style:normal; text-decor= ation:none none;} span.EmailStyle23 {mso-style-type:personal-reply; font-fa= mily:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordS= ection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.Wor= dSection1 {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 67= 698703 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-numbe= r-format:alpha-lower; mso-level-text:"%2\)"; mso-level-tab-stop:n= one; mso-level-number-position:left; margin-left:42.0pt; text-indent:-21.0p= t;} @list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:63.0= pt; text-indent:-21.0pt;} @list l1:level4 {mso-level-tab-stop:none; mso-lev= el-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-nu= mber-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:l= evel8 {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-numb= er-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:r= ight; margin-left:189.0pt; text-indent:-21.0pt;} @list l2 {mso-list-id:1693= 413572; mso-list-type:hybrid; mso-list-template-ids:2031769436 699536156 67698691 67698693 67698689 67698691 67698693 67698689 67698691 6= 7698693;} @list l2:level1 {mso-level-start-at:0; mso-level-number-format:bu= llet; 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-f= amily: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:1= 08.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l2:level4 {mso-level-tab-stop:144.0pt; mso-level-number-position:lef= t; text-indent:-18.0pt;} @list l2:level5 {mso-level-tab-stop:180.0pt; mso-l= evel-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-lev= el-number-position:left; text-indent:-18.0pt;} @list l2:level8 {mso-level-t= ab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @lis= t l2:level9 {mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3 {mso-list-i= d:2051028364; mso-list-template-ids:-356333876;} @list l3:level1 {mso-level= -tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @li= st 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.0p= t;} @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; tex= t-indent:-18.0pt;} @list l3:level6 {mso-level-tab-stop:216.0pt; mso-level-n= umber-position:left; text-indent:-18.0pt;} @list l3:level7 {mso-level-tab-s= top:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level8 {mso-level-tab-stop:288.0pt; mso-lev= el-number-position:left; text-indent:-18.0pt;} @list l3:level9 {mso-level-t= ab-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 cons= istent with the one of recipe view.

True. I was planning to redes= ign the recipe view  and the package view to bring them in line with t= he 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 o= ne of the following screens: Image configuration, Building packages, P= ackages, 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 sc= reen that displays after the packages are built, and the package dialogue y= ou 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, beca= use 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 vi= ew? 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 &= #8220;summary” can show all or more.

 

I agree that the Packages screen should look similar to the Recipes dia= logue 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 understan= d what's brought by what

    3. I am not sure the existing su= mmary does a good job at any of the two. Space restrictions make reading wh= at'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 fr= om top to bottom: you'll skim the recipes/packages to find something you ar= e looking for). The relationship between what brings what, represented by the highlight, is lost once you p= erform a new selection. The summary also creates a lot of clutter in the in= terface: the screen is so busy, it's hard to know what to look at.

     = ;

    [Shane]: I agree with you on &#= 8220;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 t= he 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 re= lationship between what brings what, and the sorting and searching mechanis= ms should minimise the need for scrolling. 

     

    After multiple iterations (it= took a very long time to design that screen), I believe the Included tab i= s 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 m= y concerns with it.

     = ;

    [Shane]: Both have advantages a= nd disadvantages. I don’t think it is hard to implement “Includ= ed”. On the contrary, the Summary is;-) I also like to hear some feed= backs 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 “Bui= ld 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 th= e main window at 1:39. Do you mind that we simplify by removing “Buil= d 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 s= hould have explained this better.

    I've designed the Hob interface as a multi-step process with 3 st= eps, each represented by a screen displayed in the main Hob window:

    Step 1 &= #8211; Image configuration screen: users input the build parameters, such a= s machine, base image and recipes

    Step 2 &= #8211; Package screen: this is not a mandatory step. You can skip it by sel= ecting '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 i= mage. The 'Build image' button is required to proceed to Step 3

    Step 3 &= #8211; Image details screen: the image has been built, and users can select= from a range of possible actions

     = ;

    [Shane]: I see. They are 2 diff= erent things.

     

    Since th= e above screens are steps in a process, they require an action (i.e. a butt= on) to move to the next step of the process.<= /o:p>

     

    The reci= pes 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 alre= ady built packages in the base image (if this is not correct please let me = know). 

     = ;

    [Shane]: Your assumption is rig= ht.

     

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

     

    I hope t= his 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 StorageR= 21;, or “Deploy” or “View Image files”?

     

    First of= all, you are right: 'Deploy' and 'Write to storage' are exactly the same t= hing. 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' butt= on. Clicking the button starts up the virtual machine

     

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

     

    - Otherw= ise the Image details screen shows the 'View image files' button

     = ;

    [Shane]: Can you give an exampl= e about “Otherwise”?

     = ;

    I hope t= his 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 wha= t 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 th= e user started the building image process, which can be the Image configura= tion screen or the Packages screen.

     = ;

    [Shane]: Understand. If any err= or 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 ̶= 0;load template”, the only chance for users to do “save templat= e” 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, b= ut it doesn't mean it has to stay that way.

     

    However, we think users can save any setting= s for build environments, and any selection of packages or recipes in an image even though the build doesn’t start. Then next time he/s= he can resume the job by starting with the stuffs saved.

    I totall= y agree with you that users should be able to save a template before buildi= ng the image. 

     

    Again, we are considering whether it is good= to put “load template” and “save template” togethe= r, because they are similar actions.

    I don't = think I would do it that way. 'Load template' is a way to initiate the buil= ding 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, lik= e 'opening an image', where is always available.

     

    'Save te= mplate' is something that sequentially comes after configuring the image pa= rameters. It's like a function that takes as parameters a machine and a base image (with its recipes or packages). Therefore the action of s= aving a template only makes sense when a machine and base image have been s= elected. If you represent it as a button in the toolbar, you will have to s= how 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 thos= e parameters have been set, i.e., after the 'View recipes' and 'View packag= es' buttons. 

     

    If you a= gree 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 i= mages”?

     

    I don't = think so. 'My images' would open a File Chooser Dialog

    Selectin= g an image file from the file chooser dialog would open the Hob "Image= details' screen for the selected image file.=

     

    "Vi= ew files" would open a regular file manager window in the tmp/deploy/i= mages directory. Selecting the image file from this file manager window would simply open the image in the default application assigned to the fil= e 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 direc= tory.

     = ;

    [Shane]: OK, I see.<= /span>

    7) We are thinking “My images” i= s similar as “Load template”, because the image contains the in= fo 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” =3D “Template” + ab= le 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 op= ening a template and opening an image are very different too. =

    After op= ening a template the logical next steps are: edit the parameters if you wis= h, then build. That's why loading a template brings you to the Image configuration screen, where you can edit parameters and build. =

     

    After op= ening 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 detai= ls screen, you can click “Edit Configuration” to go to the Imag= e configuration screen. Then the rest is totally the same as the above.

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

    For this part, we also consider the client/s= erver 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 R= 20;My images” always is generated on the server side, and the templat= e in “Load template” is a config file on the client side.

    It sort of makes sense to me that templates are local files, whil= e 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 local= ly, then images will also be kept locally. Is that the case?

     = ;

    [Shane]: Yes, that is. Temporar= ily we can skip the case running on client and server. We assume all are on= the client.

    8) We already saw some buttons “Settin= gs”, “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 instanc= e, At 8:24, clicking “Edit packages” will go back to the packag= e view. But what if users just make a mistake on the UI and want to go back to the window a= t 8:24?

    Well, th= ey 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 conf= iguration 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.&nbs= p;

     

    Providin= g 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 st= eps in a process can change, like in Hob. Remember than you can decide to g= o through the packages step, or skip it and build the image directly.&= nbsp;

     = ;

    [Shane]: Personally, I don̵= 7;t like to change “Build image” to a “Go forward” = button, because it would be possible that users want to rebuild the image w= ithout 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: th= ere are a few things you can do in the Image details screen. You can save y= our image as a template, you can edit the image, you can view the image files,  you can deploy or run the image when applicable, an= d you can build a new image. You can also open a Template or a different im= age. All those are reasonable next steps once you have reached the end of b= uilding process, and all of them should be present in the interface. 

    And we are thinking “Settings”, “Deploy image= ”, “Run image”, “Load Template” and “Sa= ve Template” are important for us, and whether we can use menus or buttons on a toolbar. We prefer th= e latter, and prefer we have a main window and others are all dialogs inher= ited from the main window. What do you think on this?

    I can se= e 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 progre= ssive disclosure (new options displaying as a result of user selections) th= at we use in the Image configuration screen to a breaking point. There are too many things happening in that main window. When you s= tart 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 s= teps 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 r= equire a parameter (an image to deploy or run). They could get this parameter by taking the last image that has been built, and deplo= y or run that image. But what if no image has been built yet? What if the l= ast image was built a few days ago and it's not at all the image you want t= o 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 situat= ion: I've just finished building a qemu image. The "congratulations&qu= ot; 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 th= e '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 hav= e 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 shoul= d be displayed where and when applicable. Actions in toolbars and menus are always present, which means they are alw= ays applicable, they make sense at all times, independently of the system s= tate: I call them global actions. Opening a template, opening an image or a= ccessing 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 mak= e sense in such a way that you cannot use them (which is just noise), or ma= ke them behave in different ways depending on the system state (which is co= nfusing). 

    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 thin= g. 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 ima= ges, there is no option or button to clean all (like sstate) but bitbake co= mmand has (bitbake –c cleanall). We hope to add it into the GUI.

    3. can the button “Settin= gs” 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 &#= 8220;Load Template” on the Image details screen. We also can initiate= a new build by “Build new image” and “Load Template̶= 1;, thoughts?

    Sorry, many feedbacks;-) And we are also thi= nking 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 totall= y 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 t= he main screen), but look for some alternative options to position the 'Dep= loy image', 'Run image' and 'Save as template' actions … not in the t= oolbar or menus, please! ;)

     = ;

    [Shane]: We will try our best.<= o:p>

    Another FYI, we get your feedbacks in the two pdf files you sen= t previously and are revising the UI.

     

    Thanks.

--_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255SHSMSX102ccrcor_--