We have

  1. Choose a couple D8 UIs to test the proposed designs
  2. Make static html prototypes for these screens
  3. Review the prototypes, adapt, extend the design where necessary
  4. Start patching things for real: apply style guide to Seven theme in core.
CommentFileSizeAuthor
#7 configuration.png127.63 KByoroy
#7 views-listing.png114.36 KByoroy
#7 longtext settings for Article.png112.62 KByoroy
add-article.png116.76 KByoroy
manage-display.png80.39 KByoroy
Add new view.png49.94 KByoroy
Views.png80.54 KByoroy
views 2.png84.42 KByoroy
Edit menu.png231.73 KByoroy

Comments

yoroy’s picture

yoroy commented

- node/add/article
- views, new view
- views, edit view overview page
- view, edit view overview page + modal
- field ui 'manage display' with an expanded row
- edit menu

Of course, point 4 needs further definition. Maybe we can get some Twig people excited about making this a great implementation?

And after point 3, we should also look into tackling the toolbar design and bring that in line.

Bojhan’s picture

Bojhan commented

I would focus on two/three pages with distinct purposes:

1) A big form (field creation form)
2) A table (node listing, views listing, manage display)
3) Navigation listing

That should cover most usecases. I'd argue to use field creation form, views listing, and /admin/config

lewisnyman’s picture

lewisnyman
he/him
commented

+1 to views listing, it would be nice to have dropbuttons in here.

yoroy’s picture

yoroy commented

Bojhan is right in aiming to cover the most likely use cases first, not go after the exotics.

- Views listing
- Navigation listing, like admin/config?
- A form: admin/structure/contact/manage/feedback maybe?

ry5n’s picture

ry5n commented

I was going to create a g.d.o discussion for implementation, but instead will link here from the Style Guide post, from the Sandbox and from #1088792: [meta] Seven theme battle plan for D8.

I think this is the right idea, get a short list to cover common screen types with several components together. However, let’s be specific with admin paths to avoid confusion. Example: Views listings. Are we talking about /admin/structure/views?

ry5n’s picture

ry5n commented

Also, after kicking around some code for the last week or so I feel better about some specifics for this prototyping phase. Here’s where we’re at in the sandbox:

- Right now we’re using @lewisnyman’s style guide builder (called Tensile) to break out individual style guide sections into individual html files, to make development a little more modular. I’ve moved this into the master branch; folks interested should work from there.
- I’ve set up a meta issue to track each piece we need to build: #1941462: [META] Create all components from the style guide.
- Once each component has a prototype implementation, we can start putting together pages.

We still need to nail down a list of those admin pages to build. We have some general suggestions in the comments above, but I’d like to get a list of actual admin URLs to discuss/agree on.

yoroy’s picture

yoroy commented
StatusFileSize
new longtext settings for Article.png112.62 KB
new views-listing.png114.36 KB
new configuration.png127.63 KB

Ok folks, here's your briefing :-)

table: /admin/structure/views
navigation listing: /admin/config
big form: /admin/structure/types/manage/article/fields/field_longtext (add a longtext field to a content type)

Bojhan’s picture

Bojhan commented
Status: Active » Reviewed & tested by the community

This plan is approved :) Lets do those pages.

ry5n’s picture

ry5n commented

@Bojhan @yoroy Thanks! Let’s do this!

ainz’s picture

ainz commented

Hi @ry5n can you save the psd files so that they are backwards compatible. I'm using cs5 and I've lost some of the editable regions in the file.

You can check this article http://prodesigntools.com/save-open-adobe-cs6-files-cs5-cs4-cs3.html. Probably save it as a tiff which most ps versions can import with fully editable functionality. Thanks

ainz’s picture

ainz commented
Issue summary: View changes

Updated issue summary.