Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Improvement: The Editor #180

Closed
rafaelconde opened this Issue Dec 2, 2016 · 36 comments

Comments

Projects
@rafaelconde
Copy link
Member

commented Dec 2, 2016

The Current State

screenshot 2016-12-02 15 17 42

Honestly there's a lot going on, and nothing major in need of improvement, but in the other hand there's just so much room for improvement that I think every element could use some love.

Some of the things that I focused on:

  • Clarity in the required fields, improve the tap targets.
  • The big one, make the editor more enjoyable to use, allow the user to focus on the actual writing and remove distractions.
  • Clean up the editor by moving some fields to a smaller drawer (see the bullet point above).

My Proposal

new post 2x

Some things to consider:

  • I think Markdown should be the default, and there's really no need to switch to a fancy preview in the editor itself, because we already have an actual preview taking up half of the screen 👍

  • When creating a new post, let's focus on the actual writing. Start writing. Let's keep the other metadata and required fields away until you need to fill them in.

  • On one hand we want to provide a clean and distraction free environment, on the other we have half the view with a preview of something we can't really control. It could be flashing GIFs for all I know.
    To alleviate this I think we should just change the opacity of the Preview to 65%, which can go back to 100% on hover.

  • As you can see, there's a new drawer in the bottom. When you click on it it expands to reveal some other additional metadata that you might want to fill in.
    new post metadata 2x

  • It can take up half of the screen when expanded, if there's more content we'll switch to a scroll area after that.
    new post metadata long 2x

The Empty State

With a couple more fields, which is customizable (right?) 😅
new post empty state 2x

Here's an example of a field being filled in
new post writing 2x

Validating

When the user hits the Publish button, the app should run some validation and prevent the post of being published if there's some required fields missing.

Like this
new post validation 2x


This is part 1 of the improvements to the Editor, I still have some things left to cover, but I would love to hear your thoughts and suggestions 👍 💯

@cassiozen

This comment has been minimized.

Copy link
Contributor

commented Dec 2, 2016

Wow, this is amazing! So much cleaner, I really like it!

But be aware of two things:

  • There isn't "metadata". All a collection have is a bunch of "fields".
  • There are no default or obligatory fields, which means a collection might not have a title or a body.

To cope with this, the CMS has an "inference system" - a fancy name for a built in list of rules and synonyms used to try to guess the following fields: title, short title (or short description), author and content body.

Now, I said all this to explain how it works, but what i'm trying to say is:

  • I think we should always display the name of the fields. We might infer them, but we can't just say "title" if the collection configuration defines "headline". We also can't just display a text area for the content body"because the collection might not have one.

  • Again, we don't have a distinction of what is metadata and what is not. So I love the idea of trying to separate and put the most important fields first (and we can infer them), but I don't think we should hide the other fields in a separated edit area (because they might be important for the content, not just metadata).

... And a few minor tweeks...

  • We don't have auto-saving / save as draft. It's an awesome idea we could implement in the future, but right we don't have them.
@biilmann

This comment has been minimized.

Copy link
Member

commented Dec 2, 2016

Some additions here:

General Look'n feel

It's too minimalist. Remember at all times that we're not doing a Ghost or a blog editor, etc, but a CMS that will support lots of different content types with complex content models. It's really important that we design with this in mind.

Plenty of collections won't have a main markdown body at all, and as @cassiozen mentioned, we might not have a "title" but instead a "headline" or "name" depending on the collection and the web project in question.

Hiding the labels when a field is filled in is a no-go, there should always be a clear visible label for each piece of content for the same reason.

Metadata

In the old Ember prototype we did actually have the concept of meta data:

http://cms.netlify.com

If you navigate to an entry you can open the "Settings" panel where the meta data lives. Each collection would have both fields and meta properties like this. These meta fields are actually still present in our example config.yml right now: https://github.com/netlify/netlify-cms/blob/master/example/config.yml#L17

Apart from the fields defined in meta fields in the config, we always have the slug which is not a field as such, and that the typical content author won't care about, but that we should ideally still have some way of editing...

Validations

We should have a clear way to indicate that an individual field is invalid after the validations have run.

@rafaelconde

This comment has been minimized.

Copy link
Member Author

commented Dec 7, 2016

Changes

  • Removed the Drawer 👋
  • Made Input Field's Labels always visible
  • Every field is visible.
  • More explicit field validation

new post_ empty state
new post_ writing
new post_ done writing
new post_ validation

@rafaelconde

This comment has been minimized.

Copy link
Member Author

commented Dec 9, 2016

Also, given the Open Source nature of this project, I've decided to Open Source the Design as well.
Everyone is welcome to contribute 👋

https://www.figma.com/file/N3E88guK9a2Z3OmevEN54yEi/netlify-cms

@budparr

This comment has been minimized.

Copy link

commented Dec 9, 2016

I think these are really great; very clean. A couple notes on language (with apologies if this isn't the appropriate thread for that)

  1. Is it possible where it says "new post" to instead use a word that is less specific (to blogs), like, perhaps, "item" or even something related to the collection?

  2. Where it says in the image upload interface "…drag and drop it like it's hot" is fun and friendly, but may feel out of place for some users. (I've known many highly intelligent non-technical people who are easily flummoxed by web interfaces and extra or fun words just gives them something more to think about)

@biilmann

This comment has been minimized.

Copy link
Member

commented Dec 12, 2016

Great points @budparr - I agree with both.

I think the "New " in the breadcrumb should simply be based on the label or name for the collection in the configuration so it's contextual.

Agree that we should be conservative when it comes to copy. People will use this in lots of different contexts and there are just some places where "fun" copy can just seem cheeky or out of place (imagine that the content editor is working on an obituary, and suddenly a small bit of copy like that can really seem grating)...

@rafaelconde

This comment has been minimized.

Copy link
Member Author

commented Jan 2, 2017

@budparr great points!

In the "New", like @biilmann said, is suppose to reflect the collection's name.
I've updated the Figma file with the changes 👍

@verythorough

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2017

Regarding item names, as in "New ___", I suggest adding a new property for collections, called something like singular_name. The existing name property represents the general collection title, e.g. "Blog" or "Posts", and singular_name would be used in situations like "New post" or "Edit post". Omission of the singular_name property could default to the value of name.

A similar property pairing is used in the configuration of WordPress custom post types.

@calavera

This comment has been minimized.

Copy link
Member

commented Jan 31, 2017

That's a good idea @verythorough. Additionally, we could also have a set of sane defaults hardcoded, because we already know that if the collection name is Posts or Blog you are going to create a New post. I don't think it'd be hard to maintain if we try to keep it as simple as possible.

@cassandraoid

This comment has been minimized.

Copy link

commented Feb 16, 2017

Just took a look at this, it is beautiful just a couple points to add to what other's have said:

How would I know what section is coming up or which sections exist? I personally feel that a 'form' like setting is something editors are used to seeing and therefore more likely to be comfortable to use it.

The fields don't look quite look 'clickable' to me either.

Is the publish button there so it no longer has to follow that editorial workflow set up now (you can't publish unless you go to main page)? Is there a 'save for later' or another option or do we just expect people to exit out (totally get that it says 'saved' so that should indicate but just play a lil devil's advocate.).

@cassandraoid cassandraoid reopened this Feb 16, 2017

@erquhart erquhart added this to Beta Release Sprint - Deadline March 14 in Planning Mar 10, 2017

@erquhart erquhart moved this from Beta Release - 3/14 to Backlog in Planning Mar 14, 2017

@eliwilliamson

This comment has been minimized.

Copy link

commented Mar 24, 2017

@rafaelconde I had some issues with figma so i exported to sketch and made my changes there.

Here are the image exports:

new post editing
new post error
new post initial
new post validated
home collections cards
home collections list
home queue list
home queue scrolled
home queue
login

@robsd

This comment has been minimized.

Copy link

commented Mar 24, 2017

I love the look of Netlify CMS on desktop but does anyone know when/if it will become responsive/mobile-friendly? Great work tho 👍

@eliwilliamson

This comment has been minimized.

Copy link

commented Mar 25, 2017

@robdixn I hope take a pass at it early next week depending on the feedback I recieve on the desktop concept above 👍

@imorente

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2017

@eliwilliamson this is beautiful!

One thing to keep in mind is that it's hard to know what's going on without relying on color. Once "This is an APPROVED title"/"This is an article UNDER REVIEW"/etc. are replaced with the actual title of the content, there's no good way to know

screen shot 2017-03-24 at 8 02 19 pm

@eliwilliamson

This comment has been minimized.

Copy link

commented Mar 25, 2017

@indysigner

This comment has been minimized.

Copy link

commented Mar 25, 2017

Hey @rafaelconde, the new UI design is looking fantastic. Let me add some function related inquiries / suggestions:

MVP stuff

  • Add a 'Search' input field everywhere (except for editing articles)
  • Add an image upload function that allows uploading multiple images at once. #350 (comment)
  • Add media library UI and add a link within the primary navigation #350
  • Add comment moderation #314
  • Add 'Disable Advertising for this article' checkbox to the article editor
  • Add 'Edit URL', including the date slug #377

Fancy stuff (nice to have)

  • Add checkbox for bulk actions to the list of articles
  • Navigation: Add 'APIs' to manage APIs
  • Add lock overlay when multiple users are editing the same article
  • Add Google Analytics integration

CC'ing @erquhart and @biilmann, too :-)

@erquhart

This comment has been minimized.

Copy link
Member

commented Mar 30, 2017

@eliwilliamson I just want to reiterate what's already been said: the design work here is incredible! Glad to see all of the UX considerations coming in from contributors, too. This is going to be awesome.

@calavera

This comment has been minimized.

Copy link
Member

commented Mar 30, 2017

@indysigner it would be great if those were separated issues, otherwise they will be lost in this thread.

At the moment, this is "only" trying to find a better look and feel for what we have now, and hopefully put a small design system in place for new features.

If we had those as issues, other contributors could jump of them as they feel, they can be very isolated as individual contributions.

@danielpost

This comment has been minimized.

Copy link

commented May 31, 2017

@indysigner Thanks! It's not really meant to be a full fledged page at this point, more a prototype of how different widgets could look and function. I'm planning on adding a bunch of extra ones just so we can explore different options.

@erquhart

This comment has been minimized.

Copy link
Member

commented May 31, 2017

Awesome, looking forward to it.

@imorente

This comment has been minimized.

Copy link
Contributor

commented May 31, 2017

@danielpost, I love how nice and clean that design looks, while still being really functional (good contrast, labels and form controls are clear...). Can't wait to see more!

@erquhart

This comment has been minimized.

Copy link
Member

commented Jun 27, 2017

A general design improvement will be important for 1.0. Here are my thoughts on the path forward, with feedback from all of the comments on this issue:

Aesthetics

The designs from @rafaelconde, @eliwilliamson, and @danielpost are all moving in a generally solid direction. Whatever we settle on aesthetically needs to be effectively communicative, accessible, cohesive, and scalable. As Mathias mentioned, this CMS has to cover use cases we can't even think of right now, so we'll want to avoid bending toward a particular kind of content.

Markdown by default

I agree with using Markdown as default (in a sense) and eschewing the dual editor approach. I think the rub here are two somewhat conflicting goals:

  • allow folks that really like markdown to just write markdown
  • let others not have to think about markdown

Because we'll soon be using Slate for the visual editor, we can easily offer a Paper-like experience by default (Markdown shortcuts, where the markers disappear) with the option to show the markers if desired. Slate has examples of both in the Markdown Shortcuts and Markdown Preview examples, respectively.

All of that said, this should probably be handled under a different issue.

List vs. Card

For now, it may be best to use a list for entries and search results, but retain the card UI for the editorial workflow.

The rest

  • Dimming the preview - the preview can already be hidden, that should cover it for now.
  • Metadata editing - yes, please. Especially for slugs.
  • Copy professionalism - we should probably err to the side of boring. Clarity first.
  • Omnipresent search bar - requirement.
  • Media library - covered under #350.
  • Comment moderation - covered under #314.
  • Disable advertising checkbox - projects needing this can add a boolean widget field.
  • Add edit URL field - we can edit the slug, but the URL is up to the build system.
  • Bulk actions - out of scope, definitely nice to have. Separate issue would be great for this.
  • API management - should be covered in the Config UI, see #341.
  • Indicate multiple users editing - separate issue.
  • Google Analytics integration - separate issue.
@kosirm

This comment has been minimized.

Copy link

commented Oct 4, 2017

Sorry, but I can't not to comment on this: I really don't like whole idea of side by side editing in netlifycms. Please re-consider front-end editing. Otherwise people will just stay with cloudcannon & similar. Side by side editing is for geeks, "normal" people hate it, especially designers :)
There are many tools already developed (like https://github.com/sofish/pen, maybe not best example) which could be used. For wordpress users opensource tools like elementor are normal here and here (again, maybe not best example) so why not bring this also to netlifycms? Best regards.

@Benaiah

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2017

@kosirm the preview pane can be disabled trivially by either the user themselves or by disabling it for a collection in the config. Does that work for what you're looking for, or are you talking about something more involved?

@andreasvirkus

This comment has been minimized.

Copy link

commented Oct 5, 2017

@Benaiah I think @kosirm means live editing. Something similar to what Mavo.io does (a demo: https://mavo.io/demos/homepage/)

@kosirm

This comment has been minimized.

Copy link

commented Oct 5, 2017

@andreasvirkus whatever frontend technology (mavo looks really nice project, thanks for link). Idealy cms would cover multiple roles: designers, content editors, translators, etc. For some of them live editing is desirable, designers just need more broad access to structure and style (html dom) then content editors, but for translators probably best UX would be table view with text fields, etc. What I miss with netlifycms is really open architecture. Under warm "bateries included" feeling I hope to find replacable parts and not api with 4 methods. For example, I tried to implement this nice opensource template editor, but I was "short", not sure if because of my poor knowledge of react or because it is not possible at all... I invested some time to learn a bit hugo and react, which I never used before just to be capable to use netlifycms, because I really like it, it has great community and all... so to summarize, I hope netlifycms could be also front-end agnostic, not only back-end agnostic with strong and clear api in both directions.

@tech4him1

This comment has been minimized.

Copy link
Collaborator

commented Oct 5, 2017

@kosirm I think the markdown editor that Netlify CMS already has is a core part of how the CMS works. One of the main differences that I see between the examples that you are providing (Mavo, CloudCannon, GrapeJS) is that they all edit HTML directly instead of Markdown. How are you thinking these would integrate with the CMS' markdown centric workflow? If you are thinking of it as a new feature, that would allow different front-ends to be hooked in, then maybe we should continue discussion in a separate issue.

@kosirm

This comment has been minimized.

Copy link

commented Oct 5, 2017

@tech4him1 that's exactly what I expect netlifycms to do - all up'n'down stuff (besides everything else what is doing - git workflow, netlify upload, etc), just do it behind the scenes, please :)

This is how I would like to see netlifycms:
cms

Maybe I'm just in the wrong place, sorry if this is so.

@erquhart

This comment has been minimized.

Copy link
Member

commented Oct 5, 2017

@kosirm the CMS isn't meant to be used only with websites - the content that is created and edited in the CMS might be used in any number of non-website applications (mobile apps, for example).

If you can give a concrete example of what kind of interface and end result you're expecting (the graph above is super high level), we can discuss more, but I'd ask that we move this conversation to our Gitter channel: https://gitter.im/netlify/netlifycms.

@Benaiah

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2017

@kosirm, here's a paste of some of my earlier discussion regarding this in Gitter:

The issue with live editing isn’t Markdown vs HTML - we aren’t really tied to markdown in any way except having a bunch of support for it. The issue with live-editing a site is that we have very little knowledge of or control over how the content we edit ends up in the final product. We try to sort-of-imitate the final site with the preview system, but it’s not exactly the same. We could definitely improve the UX of that, perhaps by bringing the control and preview panes together somehow, but it won’t be the edit-the-site-directly approach @kosirm seems to be looking for.

As for that template editor, that may actually be feasible (depends on the architecture of that particular library). It just needs to be embeddable in a widget (so it needs to work inside React) and be able to serialize its data to text so we can save it.

@kosirm

This comment has been minimized.

Copy link

commented Oct 5, 2017

@erquhart thanks, ok see you there @Benaiah thanks, sorry I don't get "we have very little knowledge..." sentence, maybe I'm a little dumb though :)

@tech4him1

This comment has been minimized.

Copy link
Collaborator

commented Oct 5, 2017

@kosirm The CMS is designed just to edit the content itself, it doesn't know what the final output or styling will be.

@erquhart

This comment has been minimized.

Copy link
Member

commented Dec 9, 2017

A lot of this (original issue aim) was realized in 1.0. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.