Thanks all for taking the time to look at the design and provide feedback! I need some time to digest your comments: hopefully we can discuss during the Toaster meeting either this or next week.
Cheers Belén On 26/06/2015 09:31, "Damian, Alexandru" <[email protected]> wrote: >Hi, > > >Thanks for putting all this together - very informative and very detailed >mockups. This gave me a great opportunity to review and take in the >interface over the last couple of days, and I thought > quite a bit about how it works. > > >I'm thinking this over from a bit of a different perspective - please >bear with the consistent comments below. The way the interface is >designed now is - select an image and modify it. This works > beautifully if you're pretty sure about what's in a specified image, and >how you want to modify it. The way I'm seeing it is a bit different - I >want to see what would be installed to the image, and modify the list of >packages that are there. The difference > is a bit subtle, but it goes more on the discoverability/exploratory >side, and less on - just add and remove a couple of packages that I know >that are there. > > >I have some comments of my own, and some replies to the comments below. > > > > >1). I think it should be easy to build your own recipes in the >Configuration page. The text entry with the build button should be no >longer the primary means of starting a build, now that we can > configure the build itself. > > >I would suggest adding a "My image recipes" box in the style of "Most >build recipes" in the Configuration, with two big buttons : "Build >selected" and "New image recipe". > > > > > > >2). For a new user, it's not obvious how to start configuring the image >contents, in the sense that "My image recipes" isn't the most obvious >place one would start to configure a build, which > is why people actually look for into Toaster. > > >I would suggest making "Type the target you want to build" and Build >button in a section similar to, and on top of the "Latest builds" >section. And add, in that section, in the project page, a > bit link "Configure the image contents". > > > > > > > > >3). Please drop the "New build" button. That button is a stop-gap measure >to launching build commands, but now we're not simply issue-ing build >commands, we are actually configuring the build. > Even if you are an experienced user, it's opaque form - small and with >very little information - makes it difficult to use. > > > > > > >4). It seems a bit strange that I can navigate to most of the Project >options via the left hand menu, but not to image recipes. The >user-defined image recipes are Project-specific, and I think > they are at the same level with the "Image recipes" and "Software >recipes", but in the "CONFIGURATION" category. > > >I don't think that having a duplicate link as a tab is a problem, but I >get frustrated by the disappearance of the left-hand-menu in the My Image >Recipes. BTW, thinking of the naming, I would > suggest "Custom recipes", because it's not clear from the links that I >can actually configure something there. > > > > > > >5). When configuring an image, I would suggest dropping the "Base image >recipe" concept, because we can't follow on updates from the base image >recipe after the custom recipe was created, and > this will confuse the user. > > >Also, the tab with the Base image recipe in My Image details, allowing >the user to change the base image for a recipe, should be taken out, >since we cannot change the base image recipe after the > initial selection. > > > > > > >6). The "Add A Layer" panel on the right hand side, I would've expected >it to be a pop-up like in the configuration page, not take me to the >Compatible layers. It completely takes me out of the > context of what I was doing - I want to customize a image for MinnowMax, >I want to add minnowmax and be done, not go to a different page, and then >have no idea how to return in a single click. > > > > > > >7). I subscribe to David's view that the popups are annoying and >unnecessary. I would suggest using box alerts as they are currently >implemented, to avoid obscuring the screen, and divert user's > attention. The feedback for immediate actions should not be in your >face. Ditto for the "data loading" spinner, let's make it a bit more >obscure. > > > > > > > > >8). How do I know what's in my image in at a certain moment ? It would be >great if I could have two tables in the image customization page - the >current contents of the image, and the packages > that are available. When selecting/removing a package (maybe we should >change the terminology from Add/Delete?), a package would disappear from >a list and appear in the second one. Also, when deleting / adding a layer >in-page, the recipes available would just > appear/disappear from the "available recipes" table. > > > > > > > > >9). In the "My image recipe", I am not sure why the primary actions that >you can take on the recipe (Build, Download, Delete) are tucked away in >the right hand side, when my focus is on the left > hand side, where I get drawn to the image name. Maybe we can move the >buttons, make them bigger, as to be clear they are the primary action you >do with a customized image ? > > > > >Cheers, >Alex > > > > >On Wed, Jun 24, 2015 at 3:25 PM, Reyna, David ><[email protected]> wrote: > >Hi Belén, > >I also appreciate the video and sample Toaster pages! > >Here are my comments, in addition to Michael's. > >1) Can we add a filter so that we can show just the packages that we can >delete? > > > > >I suggested to have two tables - one with what's in the image, and one >with what's available. I think this would cover the use case you have in >mind. > > > > > >The use case is trimming the image, where we want the 100 packages that >we wish to examine for removal not to be lost in the possible 1000's >packages that are available to add. > >2) I will admit that I was thrown by the new status pop-up, because not >only does it cover things up on my page, I also generally associate them >with spam and ad-ware. > >I understand your use for showing an action in progress, but we already >had a metaphor for that in the progress/status bars inserted (when >applicable) at the top of the page. Why a new metaphor? What does it add >that the regular model does not? I know that > it does stay visible while you for example scroll, but is that a hard >requirement? > >I also do not understand the dangling part, where I have to manual cancel >it to make it go away. For example, I understand for example its use in >the add layer parsing progress, but when it is done and says "Layer >Information updated" why do I have to manually > kill it? Could it at least go away on its own after a moment, and let >that be the clue that the process completed? > >The "Undo" feature though is nice! > > > > >I'm not sure what the Undo feature is ? Can you give me a bit more >details ? > > > > > >3) The new page can add layers in place which is nice, and I see how you >can use it to parse and show that layer's package count. However, it >appears that if I change my mind about the layer I have to go out to the >layer page to remove it? Could perhaps the > "undo" feature also be made available here? Or a layer delete icon? > >Speaking of layer parsing, don't we already have an idea of the package >count per layer from the "all packages" table? > >4) How does this interface deal with "package groups"? People will ask. > >http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky- >extend-customimage-customtasks > > >5) Concerns about package removal > >Adding packages is easy, but we (WR) have found that removing them is >weirdly hard. I am very curious how the backend package removal/exclusion >is being done, and who is doing it. In any case, we should have >disclaimers in place. > > > > >This is a limitation of the way metadata is structured and tested. The >YP developers often miss correct dependency linking because the actual >dependencies for a package (e.g. > installed libraries) were already satisfied by another chain, so they >miss specifying the dependency in the metadata. > > > > >This problem will be re-occuring during Toaster use, and until we clean >up the dependencies metadata, we need to tell the users exactly what's >going on - and enable them to timely > submit error reports about the invalid metadata. This is the only way we >can actually clean everything up. > > > > > > > * Some removed packages appear anyway in the image, because sometimes >the dependency information in the packages are not complete nor correct. > > * Some removed packages will break the build or the runtime, even >though the dependencies say it should be ok. Users should be encouraged >to test their changes early and often, and we may want to help save their >bacon with checkpoints (based on the last successful > build?) or multiple undo's so that they can back up to a working state >rather than re-starting from scratch. Just saying. > > > >- David > > >> -----Original Message----- >> From: [email protected] [mailto:toaster- >> [email protected]] On Behalf Of Michael Wood >> Sent: Tuesday, June 23, 2015 9:32 AM >> To: [email protected] >> Subject: Re: [Toaster] [RFC] Image customisation detailed design >> >> Thanks for the video Belén, Looks good. >> >> Couple of bits of feedback >> >> Creating an image recipe: >> >> I find the text in the modal too long, anything more than 2 sentences >> and my attention span is over! >> >> I found it confusing that I entered a name and clicked create but have >> not actually created anything, what about something like >> suggestion1.png >> (attached) this brings it more into line with import layer/create new >> project/form based activity. >> >> Select a base image recipe: >> >> I was looking for a way to "de/re/select" an image, we don't quite have >> the same concept here as the machines selection that I was expecting, >> where you can always select regardless of whether it's already >> selected. >> >> Add and delete packages: >> >> '.well' 1 >> >> I was expecting the pencil to do the same as other pencils and activate >> text input boxes. Obviously if you're on the Add/Delete packages page >> you can't change the base image like that so maybe not having these >> pencils would be better. I was also unsure as what the change >> version/licence would do. >> >> '.well' 2 >> >> If you've selected an image recipe and then remove the layer that >> provides it... what happens? >> >> The Build Image recipe/ Download recipe file / Delete image recipe >> buttons are somewhat easy to miss, they look a bit like progress >> buttons >> or other tabs. I wonder if they would be better off in '.well' 1. The >> Build button could be more noticeable. >> >> In general if you can avoid having data in a table that for each one >> requires extra data looking up the tables will be much >> faster/efficient. >> For example we have the dependencies button with total size displayed. >> It should be really quick to count the number of dependences, but much >> slower if we also have to retrieve the objects to get the data in them, >> such as "name" and "size". If we can do that by making it "on demand" >> that's much better, e.g. you click the button and it fetches this extra >> data. >> >> Thanks, >> >> Michael >> >> >> >> On 12/06/15 14:40, Barros Pena, Belen wrote: >> > As I mentioned in the Toaster weekly meeting last Wednesday, I've >> recorded >> > a (not so short, sorry) video showing a much more detailed design for >> the >> > image customisation feature. The video is here >> > >> > >https://wiki.yoctoproject.org/wiki/images/a/a1/Image- ><https://wiki.yoctoproject.org/wiki/images/a/a1/Image-> >> customisation.webm >> > >> > Everything that I show in the video is now available in the design >> > prototype at >> > >> > https://yoctoproject.org/toaster >> > >> > >> > Just in case you want to follow along ;) >> > >> > I think the design addresses pretty much all the feedback the Toaster >> > contributors have provided so far (listed below). The only items not >> > addressed are 1 (because it would require us to rethink Toaster as a >> tool >> > for absolute beginners and would impose a very specific workflow) and >> 8 >> > (because I haven't had time to think about how we can do this, but we >> can >> > definitely come back to it). >> > >> > Please send any comments and new feedback to the mailing list so that >> > Tiago can collect it and we can address it. >> > >> > This is the feedback we have received so far: >> > >> > 1. Should this kind of linear process be the main Toaster workflow, >> > instead of the non-linear one currently provided by the existing >> project >> > page? >> > >> > 2. Size is project configuration dependent, so all size information >> is a >> > guess, an approximation. We should probably still show it, but the >> > interface needs to present it as such (we need to make sure we don't >> > present it as it was 100% accurate information). The same for >> dependencies. >> > >> > 3. We need to create states for how the tables will look like when >> certain >> > information is missing (number of packages, sizes, etc) >> > >> > 4. We need to refine the recipe presentation in the workflow >> > >> > 5. We need to work on the way we present the actions. Do we really >> need >> > all the ones we have right now? >> > >> > 6. Replace the builds tab with a less prominent way of accessing >> build >> > information for the custom image recipe. >> > >> > 7. Provide a way to reenter the image customisation process from the >> build >> > results >> > >> > 8. Provide a way to 'select all' packages returned by a search >> > >> > 9. Do we need the reverse dependencies information in the packages >> table? >> > >> > 10. Can we add the package size to the visible dependencies >> information in >> > the packages table? >> > >> > 11. The workflow is still too complex: too many concepts exposed >> > (packages, layers, recipes). Should we just require people to build >> the >> > image they want to customise instead? >> > >> > Cheers >> > >> > Belén >> > >> > >> > >> > >> > > > > >-- >_______________________________________________ >toaster mailing list >[email protected] >https://lists.yoctoproject.org/listinfo/toaster > > > > > > > > > >-- >Alex Damian >Yocto Project > >SSG / OTC > > > > -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
