[Toaster] [RFC] Image customisation detailed design

Fri Jun 26 01:31:04 PDT 2015

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-
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20150626/6eef11a4/attachment-0001.html>