Design feedback - Revision history

Belenbarrospena: /* Editing recipes */

2015-07-16T11:17:41Z

Editing recipes

← Older revision		Revision as of 11:17, 16 July 2015
Line 248:		Line 248:

	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.		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 ===		=== Concerns about package removal ===

Belenbarrospena: /* Adding / removing layers */

2015-07-16T11:16:48Z

Adding / removing layers

← Older revision		Revision as of 11:16, 16 July 2015
Line 130:		Line 130:

	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.		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?		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?		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 ===		=== Actions ===

Belenbarrospena: /* Select a base image recipe */

2015-07-16T11:15:34Z

Select a base image recipe

← Older revision		Revision as of 11:15, 16 July 2015
Line 71:		Line 71:
	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?		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: Alex's suggestion would make sense to do as we're not tracking relationship between base and custom image after creation of custom image.		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.		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?		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).		BELEN: My concern in this case is how do we provide users enough information about the base image recipes before they select them.
	I will look into this in any case, and see what could be done.		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.

	----		----

Belenbarrospena: /* Design ARs */

2015-07-09T15:14:54Z

Design ARs

← Older revision		Revision as of 15:14, 9 July 2015
Line 306:		Line 306:

	* Redesign the project page based on the decision to expose the magic layer Toaster uses to handle custom image recipes		* 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 ~~naming~~-only stage.		* 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		* 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		* Find a way to show that the number of packages shown after parsing is a best guess

Belenbarrospena: /* Design ARs */

2015-07-09T15:14:42Z

Design ARs

← Older revision		Revision as of 15:14, 9 July 2015
Line 306:		Line 306:

	* Redesign the project page based on the decision to expose the magic layer Toaster uses to handle custom image recipes		* 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 naming-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		* 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		* 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

Belenbarrospena: /* The 'Undo' feature */

2015-07-09T15:10:45Z

The 'Undo' feature

← Older revision		Revision as of 15:10, 9 July 2015
Line 212:		Line 212:
	DAVID: The "Undo" feature though is nice!		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 ~~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.		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 ===		=== Layer parsing and package count ===

Belenbarrospena: /* Creating an image recipe */

2015-07-09T15:08:36Z

Creating an image recipe

← Older revision		Revision as of 15:08, 9 July 2015
Line 49:		Line 49:

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

Belenbarrospena: /* Creating an image recipe */

2015-07-09T15:08:22Z

Creating an image recipe

← Older revision		Revision as of 15:08, 9 July 2015
Line 43:		Line 43:

	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?		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 ===		=== Select a base image recipe ===

Belenbarrospena: /* Editing recipes */

2015-07-09T15:06:43Z

Editing recipes

← Older revision		Revision as of 15:06, 9 July 2015
Line 226:		Line 226:

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

	=== Concerns about package removal ===		=== Concerns about package removal ===

Belenbarrospena: /* Adding / removing layers */

2015-07-09T15:06:14Z

Adding / removing layers

← Older revision		Revision as of 15:06, 9 July 2015
Line 111:		Line 111:
	----		----

	ED: Would it make sense to not allow users to remove layers if custom images use recipes from them? Or at least notify user which recipes from the layer are used in custom images?		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: 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?

	=== Actions ===		=== Actions ===