[Toaster] [RFC] Image customisation detailed design (v2)

Barros Pena, Belen belen.barros.pena at intel.com
Tue Jul 14 14:50:22 PDT 2015 

After looking at the feedback I got about the image customisation design,
I've created a second version, and then recoded another video:

https://wiki.yoctoproject.org/wiki/images/9/90/Image-customisation-v2.webm


The video does not cover every single detail, but I hope it will give you
an idea of the most important bits.

As you will see, the new design is quite different from the previous one:

* Your image recipes are now called 'custom images'
* They no longer live in a separate section: they are listed with the rest
of the project compatible metadata
* The first step when you create a custom image is no longer giving it a
name, but selecting the base image recipe
* Each base image recipe has now its own page, where you can check the
list of packages it installs (if known)
* Once you have selected a base image recipe, you can no longer change it
* The parsing layers process is no longer there: you must now build the
image to get the package content if Toaster does not have the information

I think the above addresses the main issues you raised in your comments
about the first design. It also seems to simplify things quite a bit,
which should be a good thing.

Let me know what you think.

Thanks!

Belén

On 10/07/2015 09:37, "Ed Bartosh" <ed.bartosh at linux.intel.com> wrote:

>Hi Belen,
>> >
>> >MICHAEL: I found it confusing that I entered a name and clicked create
>> >but have not actually created anything
>> >BELEN: mmm, this one is interesting. What makes you think that you have
>> >not created anything?
>> >ED: I agree with MICHAEL. This step doesn't create anything, but the
>> >name. Can we make choosing base image as a mandatory step or merge it
>> >with naming somehow?
>> 
>> Oh, all right. I guess I lose 2-1 ;) I'll try to work something out.
>> 
>> >
>> >ALEX: 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.
>> >BELEN: and what do users do instead? Do they start they custom image
>> >recipes from a blank slate? That will most likely result in an image
>> >that doesn't build. Do you have an alternative starting point in mind?
>> >ALEX: The users would start from an already existing image, as they do
>> >now. What I'm suggesting is dropping the tab of possible base images,
>> >and the ability to change the base image for a custom image once the
>> >custom image recipe is created. This is the same point as below, just
>> >pointing to the tab.
>> 
>> My question would be then: what if I select the wrong base image? Or I
>> find at a later stage that a different base image would be a better
>> starting point? 
>> 
>What about allowing user to change base image only until custom recipe
>is modified?
>
>> >ED: This would make sense to do as we're not tracking relationship
>> >between base and custom image after creation of custom image.
>> 
>> Somehow it does make sense to me too. My main concern is the question I
>> posed above. 
>> 
>Your concern makes sense to me. However, if user adds or removes
>packages and then changes base image it could become not possible
>to apply previous changes. To handle such a cases UI will
>become more complex, which is generally bad thing from my point of view.
>
>> >People may get a wrong idea of tracking changes of base image in
>> >customized image if we keep showing base image name. It should be made
>> >clear that we're using base image only for fetching list of packages
>> >when we create custom image. Creation of custom image can be done
>> >similar to custimizing file in editor using 'Save as'. Users have to
>> >pick up base file and have to save it with the new name if they want
>> >to make a customizable copy of it. After that relationship between
>> >base file and custom one is lost. Can we do something similar?
>> 
>> My concern in this case is how do we provide users enough information
>> about the base image recipes *before* they select them.
>Now I start getting your idea and I agree with you. We need to give user
>possibility to see the result, i.e. to build an image. If it doesn't
>look good for some reason user should be able to change base image.
>In this case we should clearly show the user a status of previously made
>changes - a delta. If delta is not appliable to the new base image it
>should be clearly shown in UI. However, it would make UI more complex.
>
>> With a file, which
>> is the pattern you suggest we follow, you can open the file and look at
>> its contents at your heart's content. Then, whenever you have concluded
>> that you want to base your work on that file, you can start the 'save
>>as'
>> process from it. We would need to do something equivalent in Toaster,
>> specially because you are asking above that once the selection has been
>> made, you cannot change it (which I still think is a bit unforgiving:
>> "sorry, you have made your choice. If you made the wrong one, well, live
>> with it" kind of approach. I tend not to like that sort of thing: I
>>rather
>> be forgiving and give users the chance to change their mind about
>>things).
>> 
>> I will look into this in any case, and see what could be done.
>> 
>> >
>> >MICHAEL: 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.
>> >BELEN: this was my initial approach. From the UI perspective, it is
>>also
>> >tidier. Then Ed asked to see this information without having to click,
>> >and I decided to give it a try to see how it would look like. I agree
>>it
>> >is better to present it when you select a certain dependency, so I will
>> >revert to that. Sorry Ed :/
>> >ED: I tend to disagree with this. Size of the components is very
>> >important information when choosing base image. I agree that it should
>> >not be shown in the table as it'd slow UI down. However, this
>> >information is only shown when user presses the button with the number
>>of
>> >dependencies.
>> 
>> Yes, that's exactly the plan. The table will show the number of
>> dependencies. When you click on that number, you will see the size (per
>> dependency and total).
>> 
>I probably missed that, sorry. I think I saw a button with the amount of
>deps on it, so I thought Michael was against that.
>
>> >
>> >DAVID: How does this interface deal with "package groups"? People will
>> >ask.
>> 
>>>http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpok
>>>y-
>> >extend-customimage-customtasks
>> >BELEN: I'm afraid it doesn't. We know that at some point we'll need to
>> >distinguish package groups from other recipes, and break them up, i.e.
>> >allow people to remove packages from package groups. But during the
>>high
>> >level design discussions we came to the conclusion that it would be too
>> >hard to do in version 1 - see page 11 of the initial design document
>> 
>>>https://wiki.yoctoproject.org/wiki/images/3/31/Image_customisation_in_To
>>>as
>> >ter.pdf
>> >ED: Looking at existing image recipes I see "IMAGE_FEATURES +=" lines
>> >almost
>> >in all of them. This makes me think that most of the time images are
>> >customized by adding feature/groups. I think David is right here -
>> >people will definitely ask for this. It's just much more convenient,
>> >faster and understandable to deal with well defined components than
>>with
>> >packages. For example IMAGE_FEATURES += "splash ssh-server-openssh
>> >hwcodecs
>> >package-management" is quite straightforward and clear to me. It would
>> >require user to pick up 4 groups from the list of groups with clear
>> >names. However, it's much harder to say how many and which packages to
>> >pick up to add this functionality to the image. I'm afraid without
>> >introducing groups we'll make image customization different from how
>> >it's done in real life and much harder that it should be.
>> 
>> Right: I didn't explain this very well. Toaster will show package
>>groups,
>> and you will be able to add them and remove them like any other package.
>> What we will not show at this point is the content of the package groups
>> (i.e. which packages the package group installs).
>> 
>Great! Thank you for the explanation.
>
>> >
>> >Additional questions:
>> >
>> >Adding / removing layers: Would it make sense to not allow users to
>> >remove layers if custom images use recipes from them?
>> 
>> I don't think we can do this. It would effectively mean stopping users
>> from deleting layers from a project until they delete the custom image
>> that it's causing the issue.
>> 
>From other hand if we allow this it would mean that we're basically
>allowing
>user to break custom images without knowing about this. We should at least
>notify user about possible outcome.
>
>> >Or at least
>> >notify user which recipes from the layer are used in custom images?
>> 
>> You can remove layers from several places: the configuration page, the
>>all
>> compatible layers page, and now the image customisation pages. If we
>>were
>> to warn users that a custom image of theirs is using recipes from the
>> layer they are removing, we would need to show the warning in all three
>> places.
>>  
>> My question is: can we even know this, I.e. Which recipes required to
>> build a certain custom image are provided by layer x? What if we are
>> dealign with imported layers that have never been built?
>>
>I can only guess that bitbake has this information as it parses all
>layers before the build.
>
>> >
>> >There are a lot of variables available for tweaking
>> >in image recipesi: SUMMARY, DESCRIPTION, IMAGE_FSTYPES, etc.
>> >Are we going to allow changing them or allow editing recipes for custom
>> >images?
>> 
>> No plans to do this for the moment. Things like SUMMARY, DESCRIPTION and
>> SECTION we can expose via the right hand column of the image recipe
>> details page and allow users to set / edit. But I wouldn't go much
>>farther
>> than this for the time being; I don't think we want to turn package
>> customisation into a full-blown recipe writing tool.
>> 
>I think allowing user to see and edit image recipe is not hard to
>implement. We don't need anything fancy here. Just editable text
>area with recipe in it would be enough. This would bring a lot of
>flexibility to the process from my point of view.
>
>It could be marked as an advanced feature
>in UI if you think it's too dangerous for not experienced users.
>I personally think it's not dangerous at all as the worst thing user can
>do with it is to break image build, but this is easily doable by adding or
>removing package or group too.
>
>> >
>> >Current set of image recipes uses single and multiple inheritance of
>> >other image recipes. Are we going to show inheritance tree and allow
>> >inheritance in custom recipes?
>> 
>> Uff, I am going to answer "I don't think so", but I suspect I am might
>>be
>> missing some information. What I can tell you is what came out of our
>> initial design workshop (as documented in
>> 
>>https://wiki.yoctoproject.org/wiki/File:Image_customisation_in_Toaster.pd
>>f,
>>  see pages 9 and 10):
>> 
>> "We discussed removing any reference to the image recipe selected as the
>> starting point after selection takes place. However, Paul Eggleton has
>> brought up that image recipes might include certain options beyond the
>> package list that users or vendors might be keen on keeping. This means
>> that there are 2 possible ways of creating the custom image recipes:
>> 
>> 								1. By inheriting the starting point image recipe, and keeping
>> those extra options
>> 
>> 								2. By not inheriting the starting point image recipe
>> 
>> In general, Yocto Project's core images will use the option 2, but this
>>is
>> potentially something we could turn into an option users could select.
>> Although we should proceed with caution and provide a sane default,
>>since
>> we cannot assume users will know or understand the difference between
>> both, and we are not planning to expose those "options" that will be
>>kept
>> by inheriting the starting point image recipe."
>> 
>> Does the above answer your last question?
>> 
>I don't know :)
>It may confirm your "I don't think so" answer.
>I asked about this just out of curiosity, so any answer is ok for me.
>
>> Cheers
>> 
>> Belén
>> 
>> 
>> >
>> >Regards,
>> >Ed
>> >
>> >On Fri, Jul 03, 2015 at 03:42:58PM +0000, Barros Pena, Belen wrote:
>> >> I finally had a chance to work through your feedback for the image
>> >> customisation design. I've grouped it into categories and replied to
>> >>each
>> >> of the comments. It is long, so I've transferred it to a wiki page
>> >> 
>> >> https://wiki.yoctoproject.org/wiki/Design_feedback
>> >> 
>> >> Search in page for your names if you want to see the answers to the
>> >>issues
>> >> you raised. Edit the page if you want to reply to any of them, or
>>reply
>> >> here (whichever is easier for you).
>> >> 
>> >> There a few design ARs coming out of it all. The list is in
>> >> 
>> >> https://wiki.yoctoproject.org/wiki/Design_feedback#Design_ARs
>> >> 
>> >> I will be working through those next week.
>> >> 
>> >> Thanks all for your design review!
>> >> 
>> >> Belén
>> >>  
>> >> 
>> >> On 30/06/2015 13:58, "Barros Pena, Belen"
>><belen.barros.pena at intel.com>
>> >> wrote:
>> >> 
>> >> >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#using
>>>>>>po
>> >>>>ky
>> >> >>-
>> >> >>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.
>> >>Th​e
>> >> >>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 
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >-- 
>> >> >_______________________________________________
>> >> >toaster mailing list
>> >> >toaster at yoctoproject.org
>> >> >https://lists.yoctoproject.org/listinfo/toaster
>> >> 
>> >> -- 
>> >> _______________________________________________
>> >> toaster mailing list
>> >> toaster at yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/toaster
>> >
>> >-- 
>> >--
>> >Regards,
>> >Ed
>> 
>
>-- 
>--
>Regards,
>Ed

More information about the toaster mailing list