Design 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?
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.
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? Well, 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: 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.
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: About the 'undo' feature, see number XX 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.
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 :/
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 team, 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 and 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.
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
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
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: 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: 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.
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.
