Web: Phoenix Components and Screen Layout

[DeepDiver1975]

Proposed Screen Layout:

• Phoenix top bar which is fixed and is not scrollable
  
  
  
  • contains a hamburger menu which will trigger the app menu
  
  
  • contains the themable logo
  
  
  • contains the themable product name
  
  
  • contains list of icons which are injected by apps (like notifications)
  
  
  • last element is the user avatar and the user name
  
  
• app menu - triggered by the hamburger menu
  
  
  
  • lists apps
  
  
  • lists admin settings (if admin)
  
  
  • lists user settings
  
  
  • logout button
  
  
• app content area
  
  
  
  • this is the area which is full under control of the current loaded app - own component oc-content
  
  
  • this area can be used by apps at they need/wanr
  
  
  • proposed elements which will be provided by phoenix as components are.
  
  
  • app menu bar - second app specific menu bar - not scrollable - oc-app-toolbar
  
  
  • left nav bar - used for over all nagivation of the app - files tree, list of calendars, mail boxes ... oc-app-navigation-bar
  
  
  • right side bar - used for individual opeations of a selected element in the main area - oc-app-sidebar
  
  
  • footer - fixed footer which can hold information as well as icon elements - oc-app-footer
  
  
  • main content area - scroll able - all menu bars and the top bar will not follow the scroll - oc-app-content
  
  

[DeepDiver1975]

UX ideas on sidebar and file action placement - take from box

[DeepDiver1975]

• document components in pattern lib using vuepress(?) or https://storybook.js.org/

[michaelstingl]

Seems https://vueds.com/ is the most interesting tool for us. (uses using custom version of Vue Styleguidist, https://vue-styleguidist.github.io/)

Here is a comparison:
https://blog.hichroma.com/storybook-vs-styleguidist-2bd93d6dcc06

[scramb]

I think we should create a repository for vue-design-system as soon as possible. So that we can add upcoming components right here. If we approach the matter more or less clever, we can completely do without vuetify and work with our own component or pattern library in a short time. In addition, this puts us in the position of completely controlling components and processing them as required.

this would bring @felixheidecke and #490 in again.

[felixheidecke]

Please note: We need a system that allows for easy theme creation and installation. The latter can't require compilation! That means, there can be no style related CSS/less/sass in .vue files or anywhere inside the Phoenix core build. This needs to be in a separate place so it can be later added on top of an already compiled and deployed Phoenix build.

A theming system that drops static asset files (CSS and images) that can be easily uploaded to the web server is the way to go. I haven't looked @ the systems presented above but in the end, it comes down to that one requirement.

PS: I'll be back tomorrow. This is a quick intermission ;-)

[DeepDiver1975]

There was some discussion on the theming/branding topic yesterday between @ChrisEdS @michaelstingl and myself. We are more in favor of a branding system which allows changing explicitly defined parameters then having a full theming support which allows all styling changes as we do today in owncloud.

Downside of theming today is that on each and every major produuct updates all themes need to be retested and adapted. Where as a branding concept is expected to work out of the box.

I will sit together with @ChrisEdS in the next weeks and apply some of our existing themes to phoenix to see what's missing in our branding capabilities.

Please note that for some screens - like the login page we can use an approach which allows full replacment of the page if needed. We will see.

[felixheidecke]

_We are more in favor of a branding system which allows changing explicitly defined parameters then having a full theming support which allows all styling changes as we do today in owncloud._

Why set ourselves, customers and the community that limit? Tech reasons only? We are in fact restricting more of what was possible before.

[DeepDiver1975]

Downside of theming today is that on each and every major produuct updates all themes need to be retested and adapted. Where as a branding concept is expected to work out of the box.

because of this

[felixheidecke]

Downside of theming today is that on each and every major produuct updates all themes need to be retested and adapted. Where as a branding concept is expected to work out of the box.

because of this

Doesn't that apply to every app as well?

[felixheidecke]

I mean, we could make a great difference to our competitors, being able to fully adopt a customer's corporate design in an ownCloud theme. Let's not waste this business opportunity here.

[ChrisEdS]

As mentioned yesterday, such a "theming-system" can cover 90% of use cases. I, for my part, have to agree with @felixheidecke when he says that sometimes you need 100% to customize and make things look awesome. We should consider that.

[michaelstingl]

We'll have a live deployed version soon. Then we can have a closer look…

[DeepDiver1975]

All required components have been implemented. I'll open follow up issues to discuss next steps.