UI Update discussion #5937

Open techknowlogick opened 5 years ago

Per discussion in #5932, and @kolaente's suggestion. I am opening this ticket so we can discuss future of Gitea UI

I would love to see this happen as Gitea isn't very usable on mobile devices, but this would be a massive undertaking and one that I hope would not take away all the developers from maintaining and working on regular features for Gitea. :smiley:

Focusing only on CSS now, I have two primary concerns:

semantic-ui is a dead end technology-wise. It does not embrace flexbox and I generally think it's doing to much on its own. I'd prefer to be in a bit more control, maybe just by adding some helper classes.
less is probably not needed. I think selector nesting is a bad because it leads to uselessly long selectors that are hard to search for in the source. With CSS supporting variables, I don't really see much use in having a preprocessor. I'd suggest converting to plain CSS.

Dropping less in favour of native css variables would mean dropping support for some browsers, but I guess I'd be okay with that since most of the people using Gitea are devs anyways who usually are using up to date browsers. A bigger problem for me would be to not be able to use things like darken($color) and being able to split the css in multiple files which would then be combined into one single css (I know native css can do that too... kind of)

A new design might also help to make it more clear Gitea is much different from Gogs because as of now, both share pretty much the same ui.

Framkework-wise, I'd throw bulma.io in the mix as that is something I've used in the past and found it pretty good. I takes the hassle out of most things while still allowing high custimization and therefore easy theming.

I think that giving Gitea its own unique UI is something that would certainly help show the difference between it and Gogs, At the same time I have to say that less or scss is probably something that should continue to exist in this project as some of their functionality is not available in CSS, framework wise I have no opinion that would benefit this discussion since I personally just use Bootstrap 4 for my projects (not something that should be used here)

Bulma sounds good to me :) thought it means full UI rewrite sadly

I am definitely in favor of plain CSS and using standards like Flexbox and Grid over frameworks. Grid provides a lot of features that non-Grid frameworks cannot.

@andrewbanchich Bulma is based on flexbox

Yes, but if it isn't based on Grid then it's still a framework that is using something in a way it wasn't meant for. First, grid frameworks used floats for layout, which was a workaround since floats weren't meant for any kind of layout. Now they are using Flexbox for the full 2D layout, but Flexbox is only meant for 1D layouts. Grid is meant for 2D layouts, and it can do things Flexbox cannot very easily, so I feel like we should just use the standard CSS Grid. In my opinion, there isn't much need for a grid framework anymore.

Bulma is very lightweight and gives you quite nice looking style out of box, I don't think we have designer who could do us nice looking design for gitea here

@lafriks I really liked @kolaente's design.

A bigger problem for me would be to not be able to use things like darken($color)

Agree, I certainly need those as well and there is no clean CSS solution for color adjustments like this. I personally prefer SCSS over LESS, but for light usage, both should be about equal.

but if it isn't based on Grid then it's still a framework that is using something in a way it wasn't meant for

Grid is certainly an option, but are there any suitable frameworks based around it available?

Here's a draft I played around with: (written in Bulma)

screen shot 2019-02-27 at 22 03 55-fullpage

I'm not quite happy with it.

@kolaente can you share it in some separate git repo somewhere? As I have been playing with bulma also and would be nice to work on this together

@lafriks Sure: https://kolaente.dev/konrad/gitea-design

The design made by @kolaente reminds me of Gitlab a little bit. It's great that there is a topic to discuss an enhancement of the UI. Personally i like the desktop design because it is close to Github. I guess this may help many developers to get started with the service.

Sometimes i add issues via my phone. The UI can be used, yes. But some other services have a better responsive UI. Unfortunately i am not that good with CSS.

Maybe Twitter Bootstrap could be used to be responsive (you can only select grid for example) and the other components like buttons have the custom layout.

@mbedded it uses @jgthms's Bulma, which is a responsive CSS framework as well.

Here's a draft I played around with: (written in Bulma)

I like GitHub's (everything in the middle) design more than GitLab's. I find it less distracting.

I'm new here - it started with opening issue #6687 and looked at less code and ask about a solution in sass. Afterwards @techknowlogick pointed me to this issue.

GitHub I like design of GitHub, but lately with many new features it gets crowded. Status setting in drop-down, new experimental features in sidebar. -> Many different menu types. Most stuff moves to a side menu like new checks feature (also breaks the design in width). Looks like Github has a problem to fit everything into the website.

GitLab/Bitbucket Not only GitLab uses the sidebar. Many Services switched to a sidebar, because it is easy to find & expand. Every entry and sub-entry on same element. It works on mobile up to 5k display (little bit lost) and easy to integrate outside of main content. The header area starts with information of this current page topic. If you add a new feature or provide a plugin system, it is enough space to add a new (sub-)menu entry.

Css/ vs. sass Use a compiler :) Css various from browser to browser and tools like a autoprefixer fixes a lot of small issues without writing multiple lines for every browser and dropping it later. Also features like nesting color variables and functions like darker/lighter, rgba($color, .8). With a linter you can enforce to only use colors as variables max nesting depth. Adjusting variables for a new theme is really easy.

Bulma theme Looks good (single maintainer/no organization account), not standard bootstrap, material-design or (zurb-)foundation. Would only import the wanted components. Bulma sass syntax is uncommon. Compared with bootstrap more sizes are hardcoded.

I will use gitea either way, but i would like a improved dark theme (no stylus patch) and without variables more work to adjust something and get every page. Maybe i can help a little bit with style stuff, it it is wanted.

On topic of a sidebar or other major redesigns: I think a main appeal to many users is that Gitea's UI is so similar to GitHub. If we change layout fundamentals like adding a sidebar, it will be very disruptive to users accommodated to the current layout and GitHub. I'm not sure I would accept it.

Like @silverwind said: I guess it's very easy for users to switch or use Gitea if they are familiar with Github because the UI looks nearly same. On the other hand (as @xf- said): Putting the menu on the left side makes it easier to group settings or menu items. Furthermore most screens are wide ones. So a menu on the left side gives permanent access to these items and doesn't discrupt the content. Maybe the topic "where to put the menue" has to be discussed at a later point if there are more than only 3-4 items.

Maybe starting with using variables and mixins for more consistency in current theme.

For Example. A private repo in sidebar hat 36px height and a public repo or organization 35px. Also Organization have less margin to left side. Also the width of both container is different. In profile second row of organizations has no margin t first row.

About the menu: Most navigation is OK and intuitive, but the Menus on top in settings/admin are really strange. I prefer the Menus in a list. Much easier/faster to find the wanted entry.

Also font-face is a complete mess. Lato is defined in sematic-ui.css and in index.css. I don't mean the :lang switches. I would use Noto font - Nearly every language is available, Monospaced and also emojis. (Maybe a little bit offtopic) https://en.wikipedia.org/wiki/Noto_fonts https://www.google.com/get/noto/

That's true. From my experience (i am just doing a little web design because i am more a programmer than a designer): Tools like SASS or LESS are making using CSS so easy. The possibility to use and update variables code like is awesome.

Most IDEs include a SALL/LESS compiler by default or can be added as a plugin to update the css file when the source code file is saved. True the font may be off-topic here. But it's a part of the initial post to

I am opening this ticket so we can discuss future of Gitea UI

Maybe i can help a little bit with organizing some files or convert some parts to SASS. From my point of view (opinions may differ) there are two important things which should be updated:

Responsive layout when using gitea at your mobile phone (e.g. to add issues while you are not able to use your normal device)
Improve the display of admin-settings (or personal settings, as well) because there are many many settings. A vertical menu may be better than horizontal. Some may be added depending on planned or wished features.

As example: In Github (if Gitea likes to have a design similar to Github) your "normal" items are horizontal for code, issues, wiki, milestones..

Other settings of your repository, organization or personal account are vertically listed. From my point of view this is a great design decision. In Gitea there are not that many settings yet. But compared to github (if gitea grows much) the horizontal space won't be enough or we have all to switch to 16:10 screens or television screens :)

As you can see in the following screenshots:

Github settings, personal account:

Gitea settings, system administration:

What do you think?

I think we should always keep less items on menus to handle that. Less is more. :)

Something that'd make development of custom front-ends super easy would be the (not easy) task of creating an API for Gitea servers. That way, the front-end could be written in whatever framework people are comfortable with - Mithril, React, vanilla JS, whatever.

@NetOperatorWibby Gitea has an api, it is just not feature-complete as of now, see https://try.gitea.io/api/swagger

I'm developing a bitbucket-like custom theme for gitea.

Preview:

![image](https://user-images.githubusercontent.com/2662758/57520697-dcc53380-7350-11e9-9572-2aa14ba03aec.png) ![image](https://user-images.githubusercontent.com/2662758/57520737-f8c8d500-7350-11e9-9551-ba03c324a0b9.png)

The UI library that bitbucket used is built on top of React (Ref: Atlaskit), so I integrated React into Go template with some "dirty" means.

I maintained a string-to-module mapping in JS, and exposed a render() function to window. I can call the function in every template corresponding to a page, passing a unique string and some context variables required by the page as arguments. Then, the render() function finds out which React component should be mounted onto the page and renders it with those variables as props.

Honestly, the current implementation doesn't really meet the philosophy of React apps, but it works, and in fact, it's simpler than a "real" React SPA, because you don't need to care about routers and global states.

@balthild Looks awesome! So this is essentially a "translation layer" put on top of Gitea which translates the Gitea Template to React?

@kolaente Yes. The reason is not only about the lack of APIs, but also the internationalization library. There's no JS equivalence for github.com/Unknwon/i18n, so I must format the strings in Go.

@balthild Great work, do you have a public repo for it?

@NetOperatorWibby https://github.com/balthild/bitcup The project is at an early stage. Only the dashboard page is replaced, and it has a bad experience on mobile devices.

This is somewhat unrelated but it would be cool if there was a place to find different themes. I think just letting the community know where to find themes could lead to some cool new innovative looks for gitea.

The theming is currently not abstraced enough. I could see us moving to native CSS variables to define theme colors so a theme would only consist of a set of color variables. This would also mean removing IE 11 support.

@silverwind I think Jan 2020 we can remove IE11 support, as per https://en.wikipedia.org/wiki/Internet_Explorer_11 that's when it will reach EOL

"Don't give me hope"

https://support.microsoft.com/en-us/help/17454/lifecycle-faq-internet-explorer

Internet Explorer 11 will be supported until Windows 10 is EOL

@marcstreeter It's not the default browser anymore and it won't receive any update other than critical security issues.

It's quite simple: If IE is blocking us from shipping a feature, it's support is going to be dropped.

All good - just making sure the decision wasn't based on a false date.

Next steps for JS modernization should be:

Add Webpack - https://github.com/go-gitea/gitea/pull/8440
Add Minifier - possibly https://github.com/go-gitea/gitea/pull/8440
Add Babel which allows us to write modern JS while supporting older browsers.
Source JS depencies from npm where possible instead of vendoring them. This will make updating them a breeze.

@silverwind You may want to consider using modern JS on modern browsers. Here's an article about it: https://philipwalton.com/articles/using-native-javascript-modules-in-production-today/

@mrg0lden There's a lot to be done, but doing all these advanced optimizations can be a maintenance burden, especially in regard to webpack configs. Some sort of "batteries included" way of bundling frontend code that doesn't need much config would be ideal.

If you end up doing this, please use a toolkit with proper accessibility for its stock widgets, and don't make custom widgets unless you want to make them accessible.

@silverwind Have you ever had a chance to try parcel? It's purpose is to be exactly that, a zero-config js bundler, it already handles minification and also has a dev server with HMR.

I have worked with JS for the past couple of years and I'm more than happy to help if needed.

I did try parcel in the past but found it a bit lacking in terms of configurability and module ecosystem. I guess webpack is still the golden standard when one needs flexibility, even thought it's configuration syntax sucks.

Actually vue-service-cli does make webpack configuration for Vue projects a lot easier

@lafriks I think such SPA tools assume HTML is served via webpack which is not the case for us currently. We may be able to serve just index.html via webpack but it will not be easy.

Let's do it step by step. We can start from a simpler page.

@silverwind no, it will generate index.html but you can easily serve that from golang

Yeah, I guess we could attempt moving index.html to webpack eventually so we could use one of the existing webpack config templates. It' doesn't strictly have to be the vue one because last I checked our vue usage was very minimal so it could easily be converted to something else if we desire.

I think Gitea should not be a SPA, but MPA.

vote for MPA:

less resources needed on client side

EDIT: somebody can still write SPA with html+css+js by using the gitea API endpoints as backend ...

go-gitea / gitea

UI Update discussion #5937