Design feedback

Feedback

Content and labeling

MICHAEL: creating an image recipe, I find the text in the modal too long, anything more than 2 sentences and my attention span is over!

BELEN: I am sure we can improve that text to make it shorter.

ALEX: 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.

BELEN: Happy to review the labeling, as usual. I would add the word "image" though, because you cannot create custom software recipes or package groups: only image recipes. So it would be something like "Custom image recipes". Would that work?

ALEX: maybe we should change the terminology from Add/Delete?

BELEN: yes, everybody is screaming for this :) I will change it, but it needs to be changed across Toaster, not just in the image customisation process.

Creating an image recipe

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?

BELEN: Oh, all right. I guess I lose 2-1 ;) I'll try to work something out.

MICHAEL: what about something like suggestion1.png (attached) this brings it more into line with import layer/create new project/form based activity.

BELEN: that is quite similar to Tiago's sketches. I shied away from that approach for 2 reasons:

Because I find it crowded and lacking on clear priorities. There is a lot of content and controls in this screen. Most of them we need to deactivate until a name for the image recipe has been set. I am sure there are things we could do in visual design to improve the balance in such a screen, but not in this first go. The question that immediately comes to my mind when I see it is: if I cannot manipulate these content and controls, why are you showing them to me? That's why I sticked to the 2-step approach: give this a name first, so that we can create the image recipe, then, once created, you can proceed to "configure" it.
Because it meant we need 2 different custom image recipe pages: one for when you are creating the image for the first time (with the steps numbered and the name field at the top), and a second one for when you are editing the image recipe after creating it (with the name you gave before as the heading 1, and no steps). Splitting the naming step from the custom image recipe page means that we can use exactly the same page for both circumstances, which I think is good.

The above is just the rationale behind my design, just to make this clear. I believe your suggestion would also work. To figure out which one would work better, we would need to test them, and unfortunately we don't have time for that right now. But I am sure we can work together to come up with something. It would be good to hear a bit more about the reasons why you prefer your suggestion.

ED: 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?

BELEN: 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 File:Image customisation in Toaster.pdf, 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:

By inheriting the starting point image recipe, and keeping those extra options
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?

Select a base image recipe

MICHAEL: 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.

BELEN: just to make sure I understand, do you mean the fact that you get a 'selected' badge next to the selected base image recipe? The initial designs for machines also indicated which machine was selected with a similar badge, until it was pointed out to me that there is no way for us to know which layer is actually providing the machine you are setting. The only thing we know for sure is the name of the machine. I do not think is critical to indicate which is the selected base image recipe in the table: you already have it on the image summary (the well1 on the right hand side). So maybe we can survive without that.

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.

BELEN: 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?

ED: What about allowing user to change base image only until custom recipe is modified? Alex's suggestion would make sense to do as we're not tracking relationship between base and custom image after creation of custom image.

BELEN: Somehow it does make sense to me too. My main concern is the question I posed above.

ED: 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.

ED: 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?

BELEN: My concern in this case is how do we provide users enough information about the base image recipes *before* they select them. 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.

ED: 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.

ALEX: 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.

BELEN: Not allowing people to change their minds about the selected base image recipe is a bit draconian. It means that if you select the wrong base image by mistake, you will be forced to discard the custom image recipe, and restart from scratch. A bit harsh. After discussing this with Paul, it turns out the agreement was the following: if you change the base image recipe, we'll drop the initial list of packages and any deletions you might have done on it (we will warn you about that before you change the base image). Ideally we would be able to remember any packages you have added, but if this is not feasible, we might be able to survive without it. I need to design this.

ALEX: When storing a custom image recipe, we have two options: store an absolute list of packages, or store a reference to a base image and a difference for the list of packages. These options are available only while working within the Toaster instance - once you export your recipe, you have to export an absolute list of packages.

Each approach has advantages and disadvantages. The functionality described above requires storing a reference + difference, in order to be able to change the base image. The reference+difference approach has the advantage of changing the package list based on the image features and current configuration, and following the upstream changes, and the disadvantage of needing parsing on each project configuration change, and possibly changing the image package list outside user's control (when the upstream base image changes).

Custom image summary (right column)

MICHAEL: 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.

BELEN: Most of the pencil icons will activate text input boxes, it's just that I didn't prototype the interaction because we already know how they work (we are just reusing the existing interaction). The pencils are the way you can change the name, the version and the license for your custom image recipe. The only exception is the pencil icon next to the base image recipe. That would be a link to the 'Select a base image recipe' page. I agree this is not consistent. In general, I think the idea of that image summary is good, but the content could be improved: so maybe we'll look into a better way to organise it and better labelling for the different items.

Adding / removing layers

MICHAEL: If you've selected an image recipe and then remove the layer that provides it... what happens?

BELEN: heh, didn't think of this one :) Any changes in the layer list, adding or removing, will trigger a parsing. Once the parsing is finished, we could flag the fact that the base image recipe is no longer provided by any project layers. But, if you have removed the layer that provides the base image recipe, I would like to think nothing happens, since we would have created a new .bb file that doesn't depend on the original image recipe. If we decide that the custom image recipe should inherit the base image recipe, well, then we would have a problem: we would need to force people to select a new base image recipe. Paul can probably clarify what would really happen, so I'll make sure to ask him.

ALEX: 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.

BELEN: you are right. We can probably just replicate the mechanism we have in the basic configuration page: an 'add layer' form with links to view all the layers and to import a layer. So if you know what you are doing, you can add the layer you need without exiting the image configuration page.

DAVID: 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?

BELEN: See the #The 'Undo' feature below. You can delete layers in these pages using the 'delete' icon in the Project Layers section (right-hand column). The ability to delete layers creates other issues though, as pointed by Michael above.

ALEX: Also, when deleting / adding a layer in-page, the recipes available would just appear/disappear from the "available recipes" table.

BELEN: Which one is the "available recipes" table? The one listing all the base image recipes you can choose from? If yes, those don't disappear if you delete a layer. Because we will know about them from the layer index, we list them always, and we allow you to select them by adding the required layer first. When you remove a layer, what changes is the button that you see next to the base image recipe.

ED: Would it make sense to not allow users to remove layers if custom images use recipes from them?

BELEN: 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.

ED: 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.

ED: Or at least notify user which recipes from the layer are used in custom images?

BELEN: 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 dealing with imported layers that have never been built?

ED: I can only guess that bitbake has this information as it parses all layers before the build

Actions

MICHAEL: 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.

ALEX: 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 ?

BELEN: agreed. I tried many options, but I wasn't particularly happy with any of them. I'll give this another go.

Dependency size

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.

BELEN: 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).

Displaying image contents

DAVID: Can we add a filter so that we can show just the packages that we can delete? 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.

BELEN: yes, absolutely. The prototype does not include filters, but the intention is adding at least the one you are asking for.

ALEX: How do I know what's in my image in at a certain moment ?

BELEN: We will provide a filter for that, as explained in above.

ALEX: 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, a package would disappear from a list and appear in the second one.

BELEN: This is a nice idea, but I don't think we have space for 2 tables. I toyed with the concept of a list of added packages that populates as you add things, to provide better visibility of your changes. This list would be on the right hand column, with the other custom image recipe information (name, version, etc). Would that do?

Notifications

DAVID: 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?

BELEN: Just to be sure, I guess you are talking about the fixed-positioned notifications that appear when you perform an action (for example, adding a layer). Their main advantage over our current notification system is that they are always visible. Since these notifications are the way Toaster provides feedback to users about their actions, that's a significant advantage. They are also a relatively common way of presenting notification nowadays (Dropbox uses them, just to give a random example, but so do lots of other web apps). Another common way is "pop from top" messages, like these ones:

https://css-tricks.com/pop-from-top-notification/

They have an example here:

https://css-tricks.com/examples/PopFromTopMessage/

I gave those a quick try, but didn't play nice with the fixed top bar we are currently using in Toaster.

I can tweak the design a bit to make the fixed-positioned notifications less offensive (smaller, with less shadow, for example). If you would like to find a completely different way to handle notifications, let's open a Bugzilla entry and I can definitely do that at a later stage.

DAVID: 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?

BELEN: yes, this we can definitely do. We just need to come up with the right time interval.

ALEX: I subscribe to David's view that the popups are annoying and unnecessary.

BELEN: they are not popups, just to be clear. Popups are modal. These things do not prevent you from interacting with the interface until you take action on them.

ALEX: 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.

BELEN: well, it kind of needs to be. Feedback is incredibly important in interfaces: users must know the state of the system and the outcome of their actions. Notifications should be therefore visible (the ones we have right now not always are), and that's why so many web applications are using fix-positioned ones like these to provide feedback to users.

ALEX: Ditto for the "data loading" spinner, let's make it a bit more obscure.

BELEN: Michael and I spent a good deal of time trying to work out the best way to present this using the standard UI widgets that come with Bootstrap. I still think the way it is right now is the best way we can currently make it. That doesn't mean it cannot be improved. I am sure Levi will be ok with including a 'data loading' UI component in the library he is creating for Toaster.

The 'Undo' feature

DAVID: The "Undo" feature though is nice!

BELEN: "undo" features are very, very nice, I agree. I've added it here as suggested by the rest of the design contributors, but the reality is that I don't expect it to be part of the image customisation feature, that's why I don't really mention it in the video. "Undo" should probably be designed and implemented as an application-wide feature, which means it should work for pretty much all actions. This poses a certain problem for us, since "undoing" adding a layer might not be as easy as "undoing" removing a package from a custom image recipe. What I mean by this is that 'undo' requires some thought. We can open a Bugzilla entry to design an "Undo" feature for Toaster, but it will not be part of the image customisation work.

Layer parsing and package count

DAVID: Speaking of layer parsing, don't we already have an idea of the package count per layer from the "all packages" table?

BELEN: I am a bit confused by the "package count per layer" sentence. In the image customisation process, what matters is not the package count per layer, but the package count per base image recipe, which is the very important information when you need to decide which image recipe you should use as a starting point.

Package groups

DAVID: 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

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_Toaster.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.

BELEN: 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).

Editing recipes

ED: There are a lot of variables available for tweaking in image recipes: SUMMARY, DESCRIPTION, IMAGE_FSTYPES, etc. Are we going to allow changing them or allow editing recipes for custom images?

BELEN: 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.

ED: 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.

Concerns about package removal

DAVID: 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.

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.

BELEN: I cannot answer your question about package removal (maybe Paul?), but good to be warned about potential problems and possible solutions. They might not make version 1, but we can definitely enhance the functionality in subsequent releases.

ALEX: 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.

"Normal" builds vs. "custom image recipe" builds

BELEN: Alex and I (together with Paul Eggleton) sat down to discuss this, and concluded that exposing the layer Toaster will use to handle the custom image recipes (let's call it meta-customimages for the purpose of these comments) might be a good idea. This is why:

Exposing meta-customimages will allow us to get rid of the 'my image recipes' section altogether, and to integrate the custom image recipes with the rest of the project compatible metadata. This also means that users can trigger builds for their custom image recipes using the existing build mechanisms: the build form that provides suggestions as you type, and the build buttons in the recipe tables. We can also reuse the layers and recipes tables, and the layer details page, to expose custom image recipes. This fits the functionality into existing concepts and structures, and should simplify the interface significantly.

Exposing meta-customimages means that we don't need to hide the meta-customimages layer from the build data, since users know the layer exists and interact with it. This keeps consistency between the configuration information and build data.

Exposing the meta-customimages layer paves the way for better integration between Toaster and Git for managing custom recipes and potentially custom layers. Until that happens, users will still need to download the .bb files for their custom recipes and add them to their custom layer to properly integrate their custom recipes into a production build.

meta-customimages is a special layer, though. Users will not be able to remove it from the project, but they can "disable" recipes within it. The "disabling" feature aims to avoid the situation where a user has a custom image recipe both in meta-customimages and a custom layer imported into Toaster.

We won't allow users to download the whole meta-customimages layer, since probably does not make sense to have a layer with just image recipes in it.

ALEX: 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".

BELEN: right, I am a bit confused about this suggestion. We decided to "isolate" the builds of custom image recipes from "normal" builds to make sure we didn't have to deal with pushing layers to Git repos. To make this separation (which is by no means ideal) as clear as possible, we agreed to create a separate "My image recipes" section, from which you cannot start "normal" builds, and from where you start only builds of you custom image recipes. If you want to integrate your custom image recipe into your "normal" builds you need to download the .bb file and add it to your custom layer, then import that custom layer into Toaster. Please read page 5 of the high-level design document available here

https://wiki.yoctoproject.org/wiki/images/3/31/Image_customisation_in_Toaster.pdf

The above is what the initial design workshop concluded. I think we are all most definitely open to new ideas, but they must involve a solution to the problem of which layer do custom image recipes go to.

ALEX: Maybe I overstated my suggestion - it was asking simply to add an extra box launch already-configured custom images in the Configuration page, not changing the page structure.

ALEX: 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".

BELEN: Again, I am confused. There is now a build form not only above the "latest builds" section, but also in all project configuration pages, in exactly the same place so that it remains easy to find for users. That component is removed from the "My image recipes" pages because we concluded we should separate their builds from "normal" builds as explained above. Your "configure the image contents" suggestion would conflate both types of builds. Again, this is something I would love to do, but we would need a way to handle the question of which layer do custom image recipes go to.

ALEX: I am not sure I fully understand the separation between the two types of builds - I did not understand the separation. In my mind, there is one single type of builds.

The custom recipes will got in an ad-hoc temporary layer created by Toaster in all cases, and this layer will show up in the build data. I suppose that there will be no obscuring of this information.

ALEX: 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.

BELEN: This is once more a consequence of the agreed separation between "normal" and custom image recipe builds. In the project page: the "builds" content spans both, the "configuration" content belongs to the "normal" builds context, and the "my image recipes" content belongs to the custom image recipes context. The latter 2 are kept separate as the outcome of the initial design workshop suggested should be done.

ALEX: Maybe we should revisit this in a face-to-face meeting ?

New build button

ALEX: 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.

BELEN: mmm, drop it from where? It is nowhere in the image customisation process. The purpose of the 'new build' button is allow you to build for any project from anywhere. I still think that's a handy thing to have, although I have no evidence to back that up. I am ok with reconsidering that feature, but not as part of this review, which is supposed to be about the image customisation design.

ALEX: ahm, right, dropping it from the top toolbar, next to the New Project button. Not part of the image customization though, but the thought was triggered by being in the Custom image page and seeing multiple Build buttons.

Design ARs

Redesign the project page based on the decision to expose the magic layer Toaster uses to handle custom image recipes
Redesign the process of creating an image recipe to avoid saving at the name-only stage.
Remove the ability to change the selected base image
Find a way to show that the number of packages shown after parsing is a best guess
In the 'my image recipes' table, see if there is a way we can see a build button in the last table column, consistent with how all other recipes are displayed
Review the content in the 'name your image recipe' modal. The help text is too long, and the heading should match somehow the button clicked ('new image recipe'). Consider change to a page, like in projects.
Change 'my image recipes' to 'custom image recipes'
Change 'add / delete' to 'add / remove' across Toaster
Talk to Michael about his suggested alternative to the image customisation page (with the name at the top as step 1, and the tabs afterwards as step 2)
Confirm with Michael if I should remove the 'selected' badge in the base image recipes table
Design the 'changing my base image' workflow. All the initial packages and any of them you have deleted will be lost. We should ideally keep the list of packages you added, but what if any of them already exists in the new base image? Think all this through.
Remove the pencil next to the base image recipe in the right column summary: its behaviour would be inconsistent with all other pencils in Toaster. Also, changing the base image recipe has big impact, so it should probably not be too easy.
Review the content of the right column summary
Asking Paul what would happen in the image customisation process if you remove the layer providing the base image for a custom image recipe
Add the 'add layer' form as is in the configuration page to the Project layers section in the right hand column
Review the presentation of the main page actions (build / download / delete)
Remove the dependency size info from the button and put it inside the popover
Add the needed filters
Add a list of packages added to the image summary in the right column
Make the fixed-positioned notifications less offensive (check the shadow and size)
Define the time interval after which the fixed notifications fade out
Ask Levi to design a 'loading' component for the UI library