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.