Hi Shane and team, In general all sounds good. I just have a couple of small comments, which I've added below.
Belen From: "Wang, Shane" <shane.w...@intel.com<mailto:shane.w...@intel.com>> Date: Fri, 3 Feb 2012 05:29:57 +0000 To: "Xu, Dongxiao" <dongxiao...@intel.com<mailto:dongxiao...@intel.com>>, "Belen Barros Pena (Intel)" <belen.barros.p...@intel.com<mailto:belen.barros.p...@intel.com>>, "Lu, Lianhao" <lianhao...@intel.com<mailto:lianhao...@intel.com>> Cc: "Eggleton, Paul" <paul.eggle...@intel.com<mailto:paul.eggle...@intel.com>>, "Purdie, Richard" <richard.pur...@intel.com<mailto:richard.pur...@intel.com>>, "Zhang, Jessica" <jessica.zh...@intel.com<mailto:jessica.zh...@intel.com>>, "Lock, Joshua" <joshua.l...@intel.com<mailto:joshua.l...@intel.com>>, "Liu, Song" <song....@intel.com<mailto:song....@intel.com>>, "Stewart, David C" <david.c.stew...@intel.com<mailto:david.c.stew...@intel.com>>, "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>> Subject: RE: RFC: Hob 1.2 design Dongxiao and I have a discussion on that again. Belen, please ignore the issue for the deployment button below, and we have several suggestions. 1. To make the Packages Screen and the Packages dialog the same. The Packages Screen is shown after users click “Build packages”. That is one step of the process. However, the content shown in the Package dialog is all what we have built out last time. It is very possible users start from there and don’t want to go back to the Image configuration screen and click “Build Image”. Sorry, I am not sure I understand. What you seem to be saying is that we will eliminate the 'View packages' button from the Image configuration screen and the Packages dialogue. Users will access packages information via the 'Build packages' option, which will bring them to the Packages screen. Is this correct? 2. As mentioned in my last email, we want to add “Clean” in the GUI. The reason is the build will fail, say, do_fetch, then we have an option to allow users to clean what we built out and rebuild. Otherwise, the sstate could be reused for the next build. Users can do it by running “bitbake –c cleanall” in the command line. But we hope to provide this feature in the GUI. If you agree the above, then the action “Clean” is for a recipe or multiple recipes, and clicking “Clean” will go to the screen at 4:00, since cleaning includes some tasks. Then we could make the Recipes dialog to be a screen, do you agree? Yes: I agree with you. Making Recipes a screen instead of a dialogue seems like a good solution. However, I am not sure the 'Clean' function should be in the Recipes screen: it should probably be an option that is displayed when the build fails. If you select it you go to the screen at 4:00 to provide information about the cleaning tasks and once they are done, you get the Recipes screen ready for you to build again. I think this 'build failed' scenario is very important, and I would like to design it carefully. Would it be ok if I work on it this week and send you some suggestions? The other reason is users can view recipes and click “Build Packages”, no need go back to the Image configuration screen. The use case is: 1) View Recipes in the Image configuration -> the Recipes screen -> Select recipes and Build packages -> Log -> the Packages screen … 2) View Recipes in the Image configuration -> the Recipes screen -> Select recipes and Build packages -> Log -> Failure -> Go back to the Recipes screen -> Clean something -> Log -> the Recipes screen -> Build packages again -> Log -> Success -> the Packages screen … 3) View Recipes in the Image configuration -> the Recipes screen -> Select recipes -> Go back to the Image configuraion -> “Build Image” 4) Nothing want to view in the Image configuration after choosing “base image” -> “Build packages” -> Log -> the Packages screen … 5) Nothing want to view in the Image configuration after choosing “base image” -> “Build packages” -> Log -> Failure -> Go back to the Image configuration -> View Recipes -> the Recipes screen -> Clean something -> Log -> the Recipe screen -> … 6) Nothing want to view in the Image configuration after choosing “base image” -> “Build Image” -> Log -> the Image details … and so on… This seems to make sense. Just a small comment about the use case number 3. I think the Recipes screen should have 2 actions: "build packages" and "build image", so that users who want to build an image directly from the Recipes screen don't need to go back to the Image configuration screen in order to build the image. 3. When build is failed, there is a “Back” button. But go back to where is determined by where you come from. I'll keep this in mind when designing the 'build failed' scenario. 4. After users open an image by “My images”, some time there should not be a “Save Template” because we don’t have build process. Let’s show “Save Template” when “Congratulations! Your image is ready!” is shown, OK? This sounds ok to me. Should we have a 'save as template' option in the Image configuration screen? Or will we just have it in the Image details screen when you get there after completing the build process? 5. In the Image details screen, “Settings” is obviously not good to be shown there. Can we remove “Load Template”? Because it will initiate a new build. Let’s ask users to click “Build new image” to be on the Image configuration and click “Load Template”. We just keep “My Images” in the last screen (the Image details screen), is it OK? And remove “Edit Packages” and “Edit Configuration”, if the build process is not executed this time. (ditto for “Save Template” in 4.) Happy with this. 6. In Josh’s email, FRI 2 image can also be run, though it is an image for real machine. Can we keep two buttons “Run” and “Deploy” on the Image details screen and let uses decide what he/she wants? I admit an error possibly happens if the image doesn’t match the action, but we just report the error. Not so happy with this one ;) If an option is going to generate an error when selected, it should not be there at all. GUI's must be defensive: they must prevent user errors. This is a fundamental principle of interaction design. We should only present the 'Run' (on qemu) option if the image is suitable for qemu running. We should only display the 'Deploy' option for live images. If there is no way to reliably determine what type of image we are dealing with and which options are suitable for them, the 'Run' and 'Deploy' functionality should not be there at all. Better wait until we find a work around. Having said that, it seems to me that using the file extension to determine what's the appropriate action for each image should work the vast majority of times. If someone has changed the extension of the image, well, that would be an edge case (how likely are people to do that?), and we should not get into the trap of designing for the edge case, which is what we would be doing if we were to display both 'run' and 'deploy' for all images. Thoughts? Thanks. -- Shane From: Xu, Dongxiao Sent: Friday, February 03, 2012 8:57 AM To: Wang, Shane; Barros Pena, Belen; Lu, Lianhao Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> Subject: RE: RFC: Hob 1.2 design One more from me that, Hob may work as a deploy tool, and in the new movie, the approach is to select “My images” and then click deploy button. I think normal user may not have such knowledge. I am still wondering if adding a “deploy” button in the tool bar? Thanks, Dongxiao From: Wang, Shane Sent: Friday, February 03, 2012 8:26 AM To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Song; Stewart, David C; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> Subject: RE: RFC: Hob 1.2 design I get one more: In the Image details screen, after opening an image file by clicking “My images”, we don’t allow to “Edit Package”, I think. Because with an image only, we can’t generate the packages from it, you can’t assume there is a build directory (tmp/), is my understanding correct? -- Shane --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
