search

ckeditor / editor-recommendations

A set of recommendations for modern editing solutions.
https://ckeditor.github.io/editor-recommendations/
47 stars 12 forks source link

Better layout for features #7

Closed fredck closed 8 years ago

fredck commented 8 years ago

The current feature page is a bit too busy in terms of it sections and sub-sections division. For example, the current Bold page: http://ckeditor.github.io/editor-recommendations/features/bold.html

In fact, right now it gives the feeling that we have more titles for sections that content inside them :)

Comandeer commented 8 years ago

Common Misconceptions: I'm unsure whether that information should be part of the specs.

I'm used to W3C's specs, which provide many anti-examples of particular features, eg. there is an example why b shouldn't be mistaken with strong. So I thought that we can also have such section in our spec. I'm not also sure if everyone would come to these issues and read discussions about a feature that interests them. Maybe "Common Misconceptions" section should just be a summary of our "anti-ideas" from here?

But because of this doubt, I realised that we're missing one important element in our layout: link to the public discussion. For now I'll put it as a nice icon in the header.

Internationalization: this is an UI feature, so the contents of this section could be moved inside UI / UX

But it's just one type of implementation concerns and I think that it could be nice to have them all in one place. Maybe just drop "Internationalization" subheading and turn "Implementation concerns" into list (similar to current form of "Common Misconceptions" section)?

Comandeer commented 8 years ago

Ok, for now I've switched off "Common misconceptions" section. I also changed "Implementation concerns" into simple list. The feature page is not longer so busy.

fredck commented 8 years ago

I like the new layout pretty much. I just find that the content in "Implementation Concerns" is directly related to what we have in "UI / UX". What if that bullet point would not simply be a paragraph inside "UI / UX", following the list there?

Also, the use of uppercased "SHOULD", "MAY", etc is nice but that doesn't mean that every "should" should be uppercased. For example, the first occurrence inside "Notes" is not a recommended "should" but simply normal part of the phrase.

Comandeer commented 8 years ago

What if that bullet point would not simply be a paragraph inside "UI / UX", following the list there?

I still believe that some non UI / UX issues will appear ;) If not, I'll join that section with "UI / UX" one.

Also, the use of uppercased "SHOULD", "MAY", etc is nice but that doesn't mean that every "should" should be uppercased.

Good point, I'll change it.

fredck commented 8 years ago

Fine for me. I think we have already a good starting point.