To save the feedbacks for tracking (2011/12/02) 1. Gray the meta layer in the first screen, and do not allow user to remove it. While meta-yocto is something that user could remove. 2. Allow users to select multiple packaging formats. 3. If the packages are already built out, we should allow users to skip the recipe build stage. 4. If the user doesn’t want to do any customization, we should allow them to directly built out the image by one button clicked. 5. Do not show the progress bar when parsing is finished. 6. We need to give user a clear show of the selected recipes/packages. 7. We need to show the image size when selecting/deselecting packages in stage 2. 8. To unify the build environment in hob and command line, the hob should have the ability to save the configurations and copy them to Yocto meta folder or edit the local.conf. 9. Modify the description part to be more friendly to end user. 10. In package list page, we need to show where the package came from (i.e. which recipe provides this package )
Feedbacks from Richard: Thanks for the presentation this morning. I was impressed to see the two step workflow on screen and it really helps to see it. I also think its helping Belen a lot as we have something visual now :) Its unfortunate we ran out of time in the meeting this morning but whilst it was fresh in our minds, Belen and I had a quick chat about where we're at. I really wish the PRC could have been party to that but I'm going to do the next best thing and write down a summary, sorry if its a bit long. Belen will reply with her feedback and comments on anything here I've missed or she disagrees with and will also work on a more detailed response next week. Firstly, we touched on the question "who are we targeting this at?". There are several contributing arguments, not least that bitbake and OpenEmbedded have always put power and capability first, ease of use second. We came to the conclusion that for this UI, we want to primarily target users without in depth knowledge of the system *but* it still has to be usable (and useful) to the more experienced users, including ourselves. Yes, its a compromise but I think its a reasonable one and a UI we don't find useful ourselves is going to bitrot and not get the love, care and attention that it needs. We need to validate this with some of the user/persona work but we can proceed on the assumption this is the best thing to do. The implication of this is that we might "hide" less essential configuration and functionality or at least draw users attention away from it but it can still be there. The less essential functionality is, the further it will be from the user's direct sight (and we will not have functionality that isn't useful to say less than 50% of the userbase). So given that, lets take each of the screens of the prototype in turn and discuss them: The initial configuration screen ================================ The most important decision on the first screen is the machine selection and the user needs to be drawn to that. There are several "nice to configure" options but these can mostly be hidden and optionally configured by the user (DL_DIR, sstate, number of threads). Even the distro probably doesn't need to be on the primary path. The number of threads should default to any configured settings or guestimate some based on the number of cpus in the system. For layers, I'd propose this be a button opening to a separate layer configuration dialogue. It would be presented to the user in the "Can't see the machine you wanted? Add extra layers here:" kind of a way. This way, someone can find and add layers but its not the first thing they see. The build/recipe selection ========================== I think rather than drop the user straight to this, we should give them a list of more friendly options: a) Build a customised image based on packages already built (unavailable on a fresh build) b) Build an image directly with no customisation <select image> (this will skip the recipes selection dialog and the packages selection) c) Build an image directly but with customisation <select image> (this will skip the recipes selection dialog) d) Allow selection of recipes to build (proceeds to existing dialog) The existing dialog layout for selecting the recipes to build needs work since we really need to give the user different "views", image based, task based or recipe based. Most users would start with an image but then tweak the list (e.g. select minimal image, add bash) Also, already built packages should be shown as such. Build Progress Screen ===================== No comments here at this time, its based on the existing code I'd imagine. The packages selection ====================== Again this needs work on the layout and on the implications of deselecting a package (does it remove dependencies or not?). I also again think different views (image/task/recipe) are needed. Is size the compressed or uncompressed size? The default selections here really need to follow any selections made in the previous dialog about what was selected to build. Ultimately I think there are some cool things we can do at this point in the UI (such as a pie chart of what's using space in the image?). These ideas are for later though, its just worth keeping them in mind. Conclusion ========== I don't think anything in here should surprise anyone and this all continues along the same development direction we've started. I really do feel the a-d) selection above will improve the experience with the two step process a lot and make it feel more natural. It should fit well within the current design too. I think Belen now really has a clear idea of what we're doing and why at the different stages and what the constraints are and this will enable her to help take the ideas above and the proof of concept to a new level. I'll let her talk about the next steps with this. It was commented we needed to "make this beautiful" and I want to make it clear there are two ways we need to work on this. One is the interaction model, make it really flow to a variety of users. This is where the comments above are directed and is something Belen can help us with. Its also clear to that we are going to need a little visual design help which isn't Belen's speciality. She's going to see if we can get a little of someone else's help with that but we need to sort some of the interaction pieces first. I'm feeling quite positive about this, its coming together! Cheers, Richard
Just assign to Belen to define and work out a clean process for hob2.
A design proposal is available in the wiki: https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast1.mov There seems to be agreement on the design approach shown by the video. I am currently working on the subsequent steps of the image building process.
a) Build a customised image based on packages already built (unavailable on a fresh build) is not implemented so far. WIP.
All feedbacks are implemented in the latest Hob development branch.
This bug is solved by hob patches in master tree.