Site redesign discussion

[drusepth]

MaterializeCSS is becoming to feel constricting and outdated, and a more frontend-focused design opens up a lot of design space in expanding Notebook.ai moving forward.

Besides a CSS redesign (and potential site restructuring), I'd also like to use a front-end framework like React or Vue.js. If anyone has any thoughts/opinions on either, I'd love to hear them -- I'm very new to both.

With the redesign, I'd like to accomplish the following larger tasks:

Back-end improvements to enable a SPA and future mobile apps:

• #55 - Content API

Front-end improvements to help users work in their notebook faster/easier/better:

• #218 - Link to new content (and create it inline)
• #203 - Automatically turn mentions of other content into links
• #7 - Content hovercards
• #60 - Autocomplete on fields with suggested values
• #155 - The tablet UI is very cluttered
• #205 - Content tags & labels

A rewrite of hardcoded content types into user-createable content types

• #206 - Users should be able to create their own content types
• Users should be able to publish their created content types for others to copy/use
• #113 - The ability to toggle content types on/off per universe
• #116 - Content links should be allowed to link to any content type
• #201 - Allowing users to create their own relation fields on content
• #214 - Reorganizing custom (and core) attributes on content types

General polish and improvements to help people customize their notebook to their liking:

• #93 - Site-wide color scheme options
• #216 - Users should be able to select from a list of icons for each piece of content

Per-content-type "apps" that can augment whitelisted content types in various ways:

• #208 - Suggesting character familial relations

I'll create milestones/issues for each of the above, but basically the big picture changes I'd like to accomplish with the redesign are:

• A responsive design that looks and works well on phone, tablet, and desktop
• A fast, intuitive UI that makes planning in Notebook.ai faster and more fluid
  • Particularly to solve the above frequently-complained-about issues
• More customization available to users in how they want to plan their worlds
  • Especially in reusable methods such as letting users design their own content types that can be shared to other users
• Opening up design space to start using big data to provide services to users relating to their content
  • For example suggesting familial relationships, pointing out inconsistencies, letting users draw maps, etc

@mpigsley Do you have any thoughts on CSS libraries (or writing our own, and how long/difficult that might be?) or React vs Vue vs something else? Other thoughts welcome (from anyone) also! :+1:

[mpigsley]

If I use a CSS library at all I use skeleton css since it's largely out of the way and very light. With either react or vue you just need to create components and re-use them very much like a CSS library so my suggestion is to not use a library and just build your reusable base components (e.g. button, input, flex-container, etc. etc.).

I will say on the React vs Vue discussion that there are a lot more mature react libraries than vue libraries. If you need a solid dropdown or modal you're much more likely to get one you like in React.

At the end of the day it comes down to the framework you want to spend your time developing in.

[rhyeen]

I know I'm way late to this party (just found out about the app recently), so let me know if this discussion as already been resolved offline, but here are my thoughts:

My thoughts on a CSS redesign

If you're going to consider stepping away from Material Design, I would first suggest considering if it is Material Design or MaterializeCSS that is actually limiting you. Material Design carefully considers user experience and makes it dead-simple to ensure an easy to understand interface, even if that interface isn't as unique as would be desired. It also carefully considers how someone with visual impairments, such as color blindness, hard of seeing, or blindness might use components. It handles keyboard shortcuts, auto-focus, blur, and animation for you. It's responsive and works cross-device. No other visual language has taken into consideration all these things as thoroughly and thoughtfully as Material Design.

When you talk about a CSS redesign, what you really need is a front-end component redesign, because there will actually be a ton of javascript that is included in each component to get the same benefits of Material Design, yet still be your own solution. This can be a pretty complex and time-consuming task.

All that being said, there comes a time when Material Design has simply too many critics to be taken seriously be all users. Either you need to utilize parts of the Material Design predesigned components, and custom builds the rest (like Google does), or wipe your hands of it.

I wouldn't recommend utilizing a different CSS library; otherwise, you will be in the same boat you are today but with a less developed style. I wouldn't utilize a bootstrap styling system either because it's often frustrating to try and overload their styles and you will often run into styling conflicts with your own custom selectors. If you're going to move away from Material, I'd suggest a complete rewrite.

Alternatively, another way to remove your dependency on MaterializeCSS and build out front-end components independent of your javascript framework is if you start utilizing web components and polymer and maybe even PolymerElements (essentially Material Design, but in web component form instead of a strongly dependent javascript library, like MaterilizeCSS). Polymer also can be imported into any other front-end framework, so you can utilize existing components (or build your own!) without being tied to a framework.

My thoughts on a front-end framework

I think you're spot-on in decoupling your back-end from the front-end. Rails apps can only go so far when you have several remote contributors and you want to perhaps move to a separate deployment cycle (and maybe even codebase!) for your front-end and back-end. Rails also does not take advantage of front-end advancements near at the pace or to the extent of other frameworks.

The way I see it, is you've got a few options that would fit your bill well.

Polymer

Let's get the odd-duck out of the way first. I would not suggest utilizing Polymer as your core framework. I've been down that road, and Polymer is just not as nice as other frameworks for app development. However, Polymer essentially allows you to have portions of your front-end be micro front-ends.

If you're not sold by the microservice movement, you should at least consider the impact of strong dependencies on frameworks for your front-end app. Imagine if you decide to go with Vue.js and it turns out, a couple years from now, the support for that framework drops off, or they pull a stunt like Google did with AngularJS and split its supporters with introducing Angular 2 (4... 6...). You'd be considering yet another complete front-end rewrite before you even finished the migration.

Now, if instead of throwing all your eggs into the single framework basket, if you build out your visual components (buttons, menus, modals, ... the things Material Design offers you) using Polymer (aka web components), you can reuse those components in any framework that you may need to migrate to in the future. Then, all you have to worry about your framework handling is the binding of the view to data.

Also, Polymer (aka web components) is here to stay. It's not a javascript library. It's brand new web APIs that all major browsers are beginning to support (which is why Polymer is still needed to fill in the gaps). Think of it as an additional web language: HTML + CSS + Javascript + web components.

Vue

Vue is really easy to pick up and get running with. It's pretty raw, so yes, you don't have the library support that you do with React, but it's (opinion:) much cleaner to work with. It also doesn't have a ton of bulk from years of alterations and paradigm shifts (like React does) and doesn't require an outside dependency (like Redux) to scale (disclaimer: still requires Vuex for state management, but it's tied to Vue).

React

React has been tried and tested and is extremely popular. It's also shown that it plans to stick around for the long haul (AngularJS, you betrayed me!). If you're planning to ever release an Android/iOS build of this project, then it'd be really easy to utilize a lot of your existing code when you go to React Native (alternatively, you could just write everything in Native for the web.

Angular 2 (4... 6...)

Although I strongly disagree with the way Google handled releasing Angular 2 (which is why I believe it isn't as dominating as it should be), the framework is very powerful and modern. It doesn't have the same historical bulk as React, but it also doesn't have as wide of adoption and libraries. I do think it lends itself to cleaner structure than React, though.

Conclusion

All in all, really it boils down to preference. All frameworks give similar performance, similar benefits, and similar results. You could write your app in any one of them and be fine. Because this is a smaller project, with more pain in achieving something like a front-end rewrite then say a larger tech company, I would highly consider a methology/framework that you believe will stand the test of time. React appears to be winning the trending battle (see trends, but I'd also consider which framework would survive through a paradigm shift (such as web components finally being entirely adopted by all major browsers).

[StorytellerCZ]

If you go with React, I would recommend taking a look at styled-components. Might be a bit of an initial investment to build the initial components in the styling you want, but I think it then provides a great freedom to build anything, even if you choose to go with some styled-components framework.