[Toaster] [RFC] Image customisation detailed design

Tue Jun 30 05:58:36 PDT 2015

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" <alexandru.damian at intel.com>
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
><david.reyna at windriver.com> 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: toaster-bounces at yoctoproject.org [mailto:toaster-
>> bounces at yoctoproject.org] On Behalf Of Michael Wood
>> Sent: Tuesday, June 23, 2015 9:32 AM
>> To: toaster at yoctoproject.org
>> 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
>toaster at yoctoproject.org
>https://lists.yoctoproject.org/listinfo/toaster
>
>
>
>
>
>
>
>
>
>-- 
>Alex Damian
>Yocto Project
>
>SSG / OTC 
>
>
>
>