Complete rework of frontend

[newhinton]

Is your feature request related to a problem? Please describe.
The userinterface is not really intuitive and very overwhelming.

Describe the solution you'd like
There are some things that could be improved:

• Move Tags to Sidebar, similar to how the files app deals with shares

• Use a Three Column Layout, similarly to the contacts-app.
  This allows for the following:

  • Categories do not need to expand, they would filter the "second"-column
  • The same applies to tags
  • The main-recipe-view will be less "filled", only a simple list will provide access, and the third colum would be empty except a recipe was selected.
  • Filtering&search can be handled more easy, removing buttons and selectors that are too tiny for people with accessibility issues

• Generally increase spacing in the Recipe-View

• Use a single-row breadcrumb, that shows categories

If you want, i could try to make mock-ups. I dont know if you have an overhaul planned, but i think some of the points could improve the app greatly!

(I think it is especially important to remove the tiny buttons, since they really interfere with accessibility)

[christianlupus]

Hello @newhinton and thank you for your suggestions.

Let me throw a few questions, I cannot yet create a mental image of what you see 😉.

• Move Tags to Sidebar, similar to how the files app deals with shares

Are you talking about the view of a single recipe or the overview page with all recipes visible?

• Use a Three Column Layout, similarly to the contacts-app.
  This allows for the following:
  • Categories do not need to expand, they would filter the "second"-column
  • The same applies to tags
  • The main-recipe-view will be less "filled", only a simple list will provide access, and the third colum would be empty except a recipe was selected.
  • Filtering&search can be handled more easy, removing buttons and selectors that are too tiny for people with accessibility issues

So, you would like a 3-col layout. That is left, middle, and right, ok. What view are we talking about right now? I suspect the list of recipes, right?
In the left column would be the categories. In the middle column would be the recipes (as a list). The right now would show the currently selected recipe completely verbosely (similar to what we are showing right now when opening a single recipe). Am I correct so far?
Where/how would you handle the keywords? What would the mobile version look like?

• Generally increase spacing in the Recipe-View

This is generally debatable. Adding some space is no big issue. However, I'd first get the structural questions clear before changing things twice.

• Use a single-row breadcrumb, that shows categories

Again the question: What view are you looking at?
We removed the breadcrumb list not too long ago. It had major drawbacks in terms of readability and functionality. Depending on the overall design: What would be the benefit? Currently, we have only selected one row on the left side.

If you want, i could try to make mock-ups. I dont know if you have an overhaul planned, but i think some of the points could improve the app greatly!

There is an overhaul coming soon with NC 25. This will have significant changes to the front end. If we wanted to change the appearance, it would be good to do it before that gets worked on. After that has been done, it would be twice the work.

Regarding your mockup suggestion: I do not want to cause you a significant amount of work that might be wasted. A rough, sketched mockup might be a good idea. A high-glossy, ready-to-be-implemented one might be a bit too early.

(I think it is especially important to remove the tiny buttons, since they really interfere with accessibility)

What buttons are you referring to? They are the size as dictated by the Nextcloud design guide. So, increasing the size is not the best idea. We tried to reduce the number of buttons recently. So, maybe you might need to clear that out with a screenshot.

I would like to ask also in the community what they prefer. Such a UI change would impact UX, of course. I would like to have consent in the community about such a change, if possible. To make that possible, the rough mockups might be a good idea.

[newhinton]

Are you talking about the view of a single recipe or the overview page with all recipes visible?

I am talking about the overview, the top row which contains all the tags collected from every recipe. The "Tag-Cloud" so to speak.

Am I correct so far?

Yes! And the keywords would stay were they are. (Not everything works perfectly in what i have in mind, but maybe i have some better ideas when i have done a mockup, or someone else has an idea)

The mobile-version should't be drastically different from now, three columns should work fine out of the box, just stacked.

My mockup was planned as an edited screenshot, cobbled together from where i can find fitting elements, thats not too much work ;)

What buttons are you referring to?

The ABC and ↓ button in the tag-cloud.

I think the contacts app is a good place because they already have a lot of the ideas i was proposing, but a mockup will follow!

[seyfeb]

@newhinton One other question: are you suggesting to get rid of the current single recipe view and replacing it with the third column in the recipe list?

We should keep in mind is that an average recipe contains much more information than a contact, especially if requested features were added in the future, such as an image for each step, additional nutrition info etc. But even already recipes can have lots of ingredients, tools and text in the instructions. Displaying as much as possible at the same time (e.g., ingredients with amounts and the instructions so you know how much of an ingredient to put in) is favorable in my point of view, while I wouldn't need to see the list of other recipes when cooking a single recipe.

[newhinton]

@seyfeb Yes i was suggesting that in principle. I habe to say that i am slightly biased, because i use the mobile app for recipe-viewing and i didnt take that into account. (But i will now for the mockup!)

Possible ideas would be to create a specific fullscreen view. But i think the recipe view also should be streamlined a bit.

[christianlupus]

Adding a fullscreen view would add another button on the screen somewhere. Also, this would add one more level of interaction in order to access a recipe: First, you select a category (optional), then you select the recipe and see it in the preview (right column). Then you click on the fullscreen view to reach the current single recipe representation. Finally, you can click on edit to modify the recipe.

Regarding the reduction of the UI in the single recipe view: There are multiple requests here in the issues to add this or that information to the recipes. All these pieces of information need to be represented, so this would rather be an extension and no reduction. I could think of hiding some information in a frame that is collapsed by default, eventually. But this would need also a clear image of what to do before starting to implement.

There is also #1240 added recently that requests a change in the UI. We should consolidate the desired UI before we continue with anything.

I am even thinking of taking the offer as suggested in #943 and asking for suggestions from the core design team. I avoided that as I thought the UI to be not mature enough and to have minor issues (we have quite some open issues ATM).

[newhinton]

Adding a fullscreen view would add another button on the screen somewhere. Also, this would add one more level of interaction in order to access a recipe: First, you select a category (optional), then you select the recipe and see it in the preview (right column). Then you click on the fullscreen view to reach the current single recipe representation. Finally, you can click on edit to modify the recipe.

That would be entirely optional. Basically a "distraction-free" view that can be enabled, but i am just throwing ideas around atm.

Regarding the reduction of the UI in the single recipe view

I am not advocating reducing stuff, but streamlining.

I suggest to not implement #1240, and i will explain why in my mockup.

[newhinton]

Spaceballs: The Mockup!

This is basically taken from the contacts app and slightly modified.

There are 3 Columns:

• Column 1 - AppNavigation:

  • Main Recipe Controls:
    Those contain the new recipe-button and the category-selectors (all/none)
  • Categories:
    Each available Category is displayed here. New ones can be added by the + sign, it should be collapsible
  • Tags:
    Each available Tag is displayed here. New ones can be added by the + sign, it should be collapsible

• Column 2 - Search:

  • Searchbar
  • Recipelist:
    This is the new recipe list. It will be filtered by tags/categories as selected by the AppNavigation, and after that, filtered by the searchterm. If empty, also show "new recipe button", that also applies tags/categories as selected.

• Column 3 - Recipeview:

  This column contains the recipe. If no recipe was selected, it should show a placeholder. But as the contacts-app does, it is probably a good idea to show the first available recipe.

  It is also structured in two columns, but only in technical terms. On the left are the description, times, keywords, metadata and so on. On the left side are ONLY the primary image and the ingredients.

  This way, we can easily reshuffle the elements if we dont have enough vertical space. The primary Image should then be the first element, the title the second. After that no changes should be made, except that the ingredients need to be inserted before the instructions.

  For that reason i suggest we dont implement scrollbars, because with this design both mobile devices and desktops (or tablets) get the same layout, which collapses to a sinlge column-design if space does not allow for more. We entirely avoid nested scrollbars, which is always a good idea.

  I should mention that this design does uses the current style, so updating this would be good for nc25.

  Editing:

  Currently we need a second view for editing. Maybe it would be a good idea (and a whole lot of effort) to "unify" those. Maybe each element should get it's own "pen" icon for editing, similarly to the contacts app. Which i already heavily rely on, but i am not guilty for that they did such an amazing job over there ;)

Edit: Fixed wrong 3. column index

[newhinton]

Okay i were thinking about tags and categories. I see those are not nessessarily the same, but in this context they behave very similar. Are both really required? Could'nt we just use tags only?

[seyfeb]

Are both really required? Could'nt we just use tags only?

tl;dr; I'd say no. 😄

Reasons being

• We would completely break the existing data and workflows of current users (see, e.g. How do you organize your recipes? #1217) . While, yes, it is stated in the README that current user are basically testers, etc. this would be a very painful break of backwards compatibility and also there is not really the need atm.

• As stated in Keywords vs Category #685 they are not the same.

  tags are an N:M relation, and categories are a 1:N relation

• This is not a real argument but rather a comment: We are using the schema.org definition of [Recipe](https://schema.org/Recipe), which is a [CreativeWork](https://schema.org/CreativeWork), which has the [keywords](https://schema.org/keywords) property. While we certainly do not need to support everything that is supported by the schema, throwing something away that could previously be imported from other websites seems a bit unnecessary

[newhinton]

tl;dr; I'd say no. 😄

Okay ^^

In my proposal (and in fact in my own recipes) they seem to behave extremely similar. I know they are by definition different, but it seemed too close to not propose this since it would clean the ui quite a bit :D

(Also it could be implemented in a non breaking way, merging keywords and tags together and treating them like filters, but this is a whole different issue and should not be here)

Edit:

I also read through the tickets and agree with them. However, we COULD improve the ui by not showing what doesnt exist, eg. if recipes do not have a category, we dont show the category-dropdown in the appnavigation

[MarcelRobitaille]

Also it could be implemented in a non breaking way, merging keywords and tags together and treating them like filters

What do you mean a non breaking way. That definitely is a breaking change for user who depend on the distinction between keywords and categories in their workflows.

I agree that some things about the UX of tags and categories could be improved, but merging them is not the solution. That ship has sailed.

[Benedikt81]

Regarding the tag/category distinction: I don't see the issue here. If you don't want to use categories, just ignore the field.

[christianlupus]

Regarding the tag/category distinction: I don't see the issue here. If you don't want to use categories, just ignore the field.

By dropping the category field, we could change the UI such that we have more space for the tags. I think this is what he has in mind, right @newhinton?

[newhinton]

By dropping the category field, we could change the UI such that we have more space for the tags.

Exactly! But i guess that suggestion sidetracked the discussion, my main idea was and still is the mockup ^^

[christianlupus]

Thank you for the mockup. That makes it simpler to discuss things.

• Column 1 - AppNavigation:

  • Main Recipe Controls:
    Those contain the new recipe-button and the category-selectors (all/none)
  • Categories:
    Each available Category is displayed here. New ones can be added by the + sign, it should be collapsible
  • Tags:
    Each available Tag is displayed here. New ones can be added by the + sign, it should be collapsible

Adding new categories and tags with the + is another issue. This is not just a UI issue, this will require major rework of the backend. There is something on the agenda but not in a quick fashion. See #731.

I would put the no category option within the list of categories. Otherwise, it seems a bit lost to me.

The tags are selectable entries, I suspect. A single click will toggle the checkmark. Am I correct?

I am a bit concerned this will quickly overflow. Many recipes add a few new tags to the system, and you end up quickly with a few dozen to a hundred tags. Then, the left column will be mostly useless.
Maybe one could add a search field there. That might help the user a bit eventually.

• Column 2 - Search:

  • Searchbar
  • Recipelist:
    This is the new recipe list. It will be filtered by tags/categories as selected by the AppNavigation, and after that, filtered by the searchterm. If empty, also show "new recipe button", that also applies tags/categories as selected.

What do you mean by if empty? If no search text is entered?

So, this would drop most of the information from the list of recipes, right? How would long titles be handled? Just cut, overflowing, or continued in the next row?

If there were more information to be shown (I am thinking of #323), where would this be located?

I am even considering if it makes sense to allow the user to search for categories/tags using search prefixes. Something like tag:Milk will return all recipes with the Milk tag attached. Then, more complex search queries could be constructed (similar to e.g. GitHub searches in issues). (I will open a new issue for this eventually.)

• Column 2 [3?] - Recipeview:

[...]
It is also structured in two columns, but only in technical terms. On the left are the description, times, keywords, metadata and so on. On the left side are ONLY the primary image and the ingredients.

This makes the image very small. OK, I see the point.

We could consider moving the timers to the right as well. These might be used during cooking/reading.

This way, we can easily reshuffle the elements if we dont have enough vertical space. The primary Image should then be the first element, the title the second. After that no changes should be made, except that the ingredients need to be inserted before the instructions.

Are you talking about a narrow device or a mobile phone in portrait orientation? With the first two columns on a tablet or small monitor, a single stacked column on the right might work out. It will not be pleasant to view and work with, though (see the other issues with the scrolling).

For that reason i suggest we dont implement scrollbars, because with this design both mobile devices and desktops (or tablets) get the same layout, which collapses to a sinlge column-design if space does not allow for more. We entirely avoid nested scrollbars, which is always a good idea.

We need st least vertical scrolling. We might be able to prevent horizontal and nested scrolling and I suspect this is important from the UX perspective. However, we need to see what is possible.

Editing:

Currently we need a second view for editing. Maybe it would be a good idea (and a whole lot of effort) to "unify" those. Maybe each element should get it's own "pen" icon for editing, similarly to the contacts app. Which i already heavily rely on, but i am not guilty for that they did such an amazing job over there ;)

I am even thinking on the contrary direction. When viewing the recipe for cooking on a smaller screen (tablet in portrait mode or phone in landscape), we might need to reduce the number of columns from 4 (left, middle, and 2x right) to 2 columns and get rid of the left two columns for the time being.

On a portrait-mode phone, we might even need to go with one column. I have no clue, how that might look in your suggestion.

I would rather not force our mobile users to use 3rd party apps. Instead, a good web app might be better, especially as this is always updated with the most recent version of the app and thus works always. In contrast, the 3rd party apps are typically a bit behind the main development.

[newhinton]

Adding new categories and tags with the + is another issue.

It doesn't have to be this way, the + button was there from the contacts app and i just left it there. If it doesn't work this way in this app, then it should just be removed.

The tags are selectable entries, I suspect. A single click will toggle the checkmark. Am I correct?

Exactly! But maybe we should not use a self-drawn checkmark there ;)

I am a bit concerned this will quickly overflow.

That is probably true for categories aswell.

What do you mean by if empty? If no search text is entered?

Empty, if the current set of modifiers do not yield a result. That is true when either no recipes exist at all, or if the selected tags in combination with a category and/or a searchterm return an empty result. (In those cases it would then be good to show a button there to create a new recipe, automatically adding those terms/categories/tags to the new recipe)

So, this would drop most of the information from the list of recipes, right?

Not nessessarily. My mockup does not show it, but i dont see why we cant add the dates there. (Albeit i dont really see a reason to add both dates, shouldn't "last edited" be sufficient?

How would long titles be handled? Just cut, overflowing, or continued in the next row?

Good question, but generally i dont think that we are limited by height in the second column. If a list item needs more height, then it could just be bigger, albeit the image will still be fixed in the top-left corner. This would also help with #323, but we should not add too much information or it gets cluttered again.

Are you talking about a narrow device or a mobile phone in portrait orientation?

Yes. A desktop-pc (landscape) will probably have more than enough space to display "4" columns, but smartphones (portrait) will not have such a luxury. Therefore all "blocks" (i consider a block to be the times, the image, the description etc, just to make sure we talk about the same) need to be on top of each other. Then we can just scroll down and see each block easily. (Edit: yes is such a great answer to an or-question. I mean both actually. This should apply to both narrow devices (maybe if my firefox is not maximized and scaled way down) and phones in portrait in general. Maybe tablets in portrait too.)

We need at least vertical scrolling.

Oh for sure! I didn't want to get rid of scrolling altogether, but nested scrolling is bad, especially on mobile. The same holds true for horizontal scrolling, but not to the same degree. (Most often, sites that need horizontal scrolling on mobile are "broken", eg. content is overflowing, and we should try to prevent it. )

we might need to reduce the number of columns from 4 (left, middle, and 2x right) to 2 columns and get rid of the left two columns for the time being.

Actually i agree on that. If the screen is not big enough, we should display only a single "column". Either recipe, search or sidebar. I think the contacts app shows how this can work.

Basically we have two modes:

• BigScreen: Show everything, 3 columns, AppNavigation,List,Recipe
• SmallScreen: Show only Recipe. Show List if no recipe is selected, make AppNavigation accessible via burgermenu.

(I guess the "4." Column is way mislabeled, but i dont think we need to have only a "single" column of blocks on screens that have the space. But it should collapse back to one in a predictable way, preferably not like it is currently.)

In contrast, the 3rd party apps are typically a bit behind the main development.

Yeah i know, i helped out with one ;) It's kinda slow in development. But besides the ui there is a point for apps: They load just faster and feel better then a "webapp". This is a tangent, but is it possible to pack this app as a PWA?

Edit: Fixed typos and added comment

[MarcelRobitaille]

If I may add my 2 cents about the 4 column layout: I don't really see the advantage. I am not against this kind of layout in general; I love multi-column layouts when I need to quickly change between entries. For example: I love the 3-column layout of the ranger file manager so I can quickly change between folders and multi-column layouts for emails where I can see myself quickly changing between messages. However, why do we need to quickly change between recipes? After deciding a recipe to cook, I don't want to the distraction of seeing a column with only tags and categories and another column with recipes I am not cooking. I would rather see more of the recipe I am making. It should take up as much of the screen as possible IMO. I don't want to have to scroll down in a narrow column with food on my hands.

The userinterface is not really intuitive and very overwhelming.

I admit the mockup looks nice, but I do not follow how adding multiple columns and having MORE on the screen at the same time makes the interface less overwhelming. Could you please elaborate on exactly what is unintuitive in the current design that this mockup solves?

What is shown in the third and fourth column before any recipe is clicked? Or is the first recipe always selected by default?

My final gripe with this mockup is not having any pictures visible in recipe list. I often decide what to cook by scrolling through the pictures, which I can recognize much more quickly than the recipe name. Maybe this is planned and just not in the mockup, which is totally understandable. However, it looks like the images would have to be rather small in this mockup. Frankly, I prefer the current design where you can see multiple rows of recipes with big icons.

I hope I am not being overly critical of your mockup, but rather giving constructive feedback, similarly to how you gave constructive feedback by saying the current design is unintuitive and overwhelming. I hope this is not taken the wrong way.

I am even considering if it makes sense to allow the user to search for categories/tags using search prefixes. Something like tag:Milk will return all recipes with the Milk tag attached. Then, more complex search queries could be constructed (similar to e.g. GitHub searches in issues). (I will open a new issue for this eventually.)

I like this idea!

I am a bit concerned this will quickly overflow.

That is probably true for categories aswell.

I don't think so. Categories are 1:N, meaning each recipe can add at most one category. The intended workflow is to use categories more sparingly than tags.

[newhinton]

I don't want to the distraction of seeing a column with only tags and categories and another column with recipes I am not cooking.

There is no reason why we cant implement a toggle for (at least one) column.

Could you please elaborate on exactly what is unintuitive in the current design that this mockup solves?

It more closely follows nextcloud's design language, and it removes elements from where they dont need to be.

Eg. the tags: currently there is a huge cloud of tags at the top, with their own tiny sort controls, that have their own scrollbar, and below that is a two column wall of pictures&text. This kind of layout is uncommon, and it also mixes two types of data together (that are only 'loosely connected)

Spearating them we have a more clean structure: Here Are all the selectors (tags&categories) and here, in the next column in reading direction are the recipes. Up until here the same amount (or probably less because less recipes are visible) of information is shown.

Only when a recipe is shown more information is displayed, but again it is neatly seperated by the column.

An alternative to the 3-col-layout would be a 2-col layout where the recipe list is replaced by the recipe, but there are a lot of alternatives that could be used.

What is shown in the third and fourth column before any recipe is clicked? Or is the first recipe always selected by default?

One option is to always show a placeholder-icon (eg. nothing), something unobtrusive that indicates that no recipe is selected. (This should also be shown if the cookbook app does not have a single recipe)

The Alternative would be to auto-select the first recipe if available. I dont know which one is better.

However, it looks like the images would have to be rather small in this mockup.

Yes in my mockup they would be smaller. I imagine that we can be flexible in size with the second column, but i think a single column works just better, because on mobile devices single columns are the default and i dont think it's a good idea to habe deviating styles.

I like this idea!

Mee too! :D

Oh and dont worry about critizising my ideas. There is quite a lot of stuff that i probably dont think about so this kind of input is important. Especially regarding you 'searching' by image, which is probably way more important than i attribute to it.

I have some ideas for that, but i will need to flesh them out a bit and then write it down later.

Edit: I just didn't add images to the mockup. If available the recipelist has to show images! ;)

[christianlupus]

I had a meeting with the official design team of the NC core last week. I wanted to ask them for their ideas related to the issues mentioned here. Here are the main results of the discussion:

The most pressing issue is the mobile view. This is no problem as the columns of the three-column layout are handled by the core Vue components. That is, one is in the list of recipes and once one activates one of the recipes, the view is shifted to the right/left and the recipe would be full-frame. The left side with the navigation could be shown or hidden as required.

As long as the width is sufficient, the ingredients should be separately scrollable. Once the space gets too narrow, a floating button should be shown (e.g. right lower corner with an appropriate icon). That would hide/show/animate an overlay that is itself scrollable. That way, also on mobile the two main columns of instructions and ingredients can be used.

The image might be better in the main column (where the instructions are located). This makes the image a little bit bigger.

Also, the usage of the sidebar was stressed out. There was no concrete example stated, but I (personally) see multiple (future) uses for the sidebar:

• Nutrition
• Reviews
• Comments from users
• Version information and meta-information about the recipe (storage location, URL, dates etc)
• Sharing

That way, we can extend the UI without cluttering the main view of the recipe.

Another issue, that might come up in the future: If there are recipes that allow multiple parts (dough, topping, filling) each with a list of instructions and ingredients, then each part should have an individual ingredient list attached. That would reduce the amount of scrolling required.

---

I put this on the 0.10.1 agenda to get it done soon but not to stop releasing an NC25-compatible version of the cookbook in general. Or do you, @MarcelRobitaille (as the most active frontend developer) consider the changes small enough to implement this in a quick PR for version 0.10.0?

[seyfeb]

Another issue, that might come up in the future: If there are recipes that allow multiple parts (dough, topping, filling) each with a list of instructions and ingredients, then each part should have an individual ingredient list attached. That would reduce the amount of scrolling required.

Quick question: Is this actually compatible with the schema.org standard? Or does this mean creating multiple separate recipes and combining them to a new one by referencing them?

[christianlupus]

ATM, this is incompatible with the schema.org standard. However, the idea of combining multiple recipes together might be an option. I have not considered that, yet.

I was more into extending the current standard in a backward-compatible way. I have not yet a solution, thus I just wanted to give an idea of what might be in the future be done, if we get the storage within the bounds of the standard managed.
Keep in mind that the schema.org standard is designed to be extended in a simple way, we might even define our own extension to it. Let's see where this brings us.

[MarcelRobitaille]

I put this on the 0.10.1 agenda to get it done soon but not to stop releasing an NC25-compatible version of the cookbook in general. Or do you, @MarcelRobitaille (as the most active frontend developer) consider the changes small enough to implement this in a quick PR for version 0.10.0?

@christianlupus I think this change would touch almost every component. I don't think we should hold the NC25 release until we can accomplish this redesign. 0.10.1 sounds good.

[MarcelRobitaille]

It more closely follows nextcloud's design language, and it removes elements from where they dont need to be.

Eg. the tags: currently there is a huge cloud of tags at the top, with their own tiny sort controls, that have their own scrollbar, and below that is a two column wall of pictures&text. This kind of layout is uncommon, and it also mixes two types of data together (that are only 'loosely connected)

@newhinton I would like to push back against this a bit. The Files app (I think it's the oldest app) still uses a left sidebar and a grid layout. They also have small "Recently edited" files above the grid which could be compared to our keywords.

To be honest thought, I don't really like the UI of these "Recently edited" items, nor do I like the way we currently display tags. I would support tags being moved to the sidebar like in your mockup. I just really hope that the grid view stays, even if it's under a toggle (Files also does this). I really like the grid view with large icons for the reasons I have already outlined.

Another thing I just thought of and I think is relevant here: The current search UX is clunky and unintutive. The search input field is behind a button. The filter input field is accessed by pressing the "Search" button, not "Filter". The search results are displayed in a new page, rather than the existing list view being filtered in real time. I quite like how this is handled in @newhinton's mockup.

[j0hannesr0th]

Hi @christianlupus what is the status/plan with this ticket?

I took a closer look at the RecipeView.vue file and think it could do with some refactoring - especially the grid system.

Desktop view:

desktop.webm

Mobile view:

mobile.webm

I suggest to remove the print function completely (or at least out of this component). Imho there should be a dedicated component for that - or even better - the PDF generation is done in the backend, not frontend. I'm not sure if the current implementation is useful and if many users print out recipes like this:

print.webm

I can refactor the component and fix the problems shown above. To avoid merge conflicts I'll wait until #1723 is merged.

Since this a bigger task it's probably helpful to have a small discussion meeting to define the goals. Feel free to contact me if you want to have conversation about this task with me.

[j0hannesr0th]

Good morning @christianlupus have you seen this comment: #1244 (comment) ?

If yes, what do you think about it?

[christianlupus]

Hello, @j0hannesr0th. Yes, I have read said comment. You need a bit of context here:
Originally, there was no grid layout. It was inserted to solve some issue with the mobile view. It allows to change the ordering of the sections (instructions, ingredients, and nutrition) depending on the view using css. This should in general work out, eventually in your example there is a bug in the code currently. See below.
With NC 25 a significant change in the UI took place. A new to entry was defined. Until then, the top body tag was used for scrolling. Now, some div in the page is used as far as I remember. This broke some of the styling and was not really fixed since. Instead (this is the topic this issue is about) a complete resign (in terms of optical representation) was planned. This is too make use and stick with the official NC suggestions and design guidelines. I have some handwritten sketches here that were worked on with the design team. They need some tweaking though as some aspects of newly issues were not taken into account.

Long story short: before any bigger code change I wanted to create from the sketches a figma/penpot design to have a working base. Eventually check before implementation with the design team once more (only the mock-up) and only then start to develop. Therefore, I would not start to change things in a quick manner. Maybe we can brainstorm on the sketches soon?

The other thing in your videos I see plenty of white (well black) space. This is definitively not intended. Can you send me the recipe if the video to check here? I have not seen it that way yet. It could also be an incompatibility with your browser (what are you using?). That could most probably be addressed quickly.

The printing was decided to be done by the browser on the past to prevent additional work in the backend with laboring a complete recipe. There are issues and feature requests for this in the bug tracker. I see them as additions to the classical printing not a replacement. Hitting Ctrl p is way faster than exporting a PDF, downloading it, opening the file and then starting to print. It is also currently a unique selling point in the NC ecosystem to allow for printing and we were commended for that feature. We might want to enhance (see bugs and features) but not remove completely, I'd say.

Are you in the matrix channel? It might be faster if we wanted to discuss some things like time scheduling for a discussion etc.