[GSoC 2014] Proposal: Re-imagining Core Metaboxes

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[GSoC 2014] Proposal: Re-imagining Core Metaboxes

Nick Halsey
Hi everyone,


I'm a student at the University of Southern California. I've been
contributing to WordPress Core for about a year, most notably to Twenty
Fourteen, and have published nine plugins on WordPress.org, most notably
Fourteen Colors [see http://wordpress.org/plugins/fourteen-colors/].
WordPress.org and IRC username: celloexpressions.


I have several ideas for GSoC projects that I'm considering proposing, and
I'd like some input on them. For now, I'll just explain one - re-imagining
core metaboxes.


The post-writing screen is the heart of WordPress. Despite its visual
editor receiving ample attention and updates--especially in WordPress 3.9,
with TinyMCE 4.0--the rest of the screen feels dated and clunky. A new
approach to taxonomy metaboxes, as well as certain core metaboxes and the
layout of the screen in general would take inspiration from the ongoing
front-end-editor project (with the goal of creating a more unified
experience between the two editing modes). A few ideas I have initially
include those proposed by Mel Choyce and Joen Asmussen along with the
content blocks concept, and/or exploring an accordion approach similar to
that of the Theme Customizer [see http://moc.co/sandbox/post-formats/ and
http://choycedesign.com/wpadmin-ui/].


The following features would be considered in-scope: all taxonomies with
core UI (core & custom, hierarchical and non-hierarchical), featured
images, post formats (a special taxonomy), discussion, author, slug, and
everything currently housed in the publish metabox.


Any project that touches this screen needs to do so very carefully, as
millions of people use it daily. The problems that faced last year's Post
Formats UI project's attempts to change this page should be carefully
reviewed and considered (while most of the issues were with the concept of
that feature, there are lessons to be learned about changing the posting
screen in general).


User testing would be key to this project's success. Initially, I would
gather information about how people use WordPress and use it to create user
test scenarios. Then, I would run user tests on the current screen to
identify the problems that need to be addressed. Besides it not being the
most modern/streamlined design, I suspect several usability issues with the
current layout. Next, I would develop three prototype UIs, spending one
week working on each, and user-test all of these with the same test cases.
After evaluating the results of the tests, one UI concept would be selected
for full development and iterations.


This work would be developed in a plugin, but with every intention of being
added to core upon successful completion of the project. In order to assure
that this is a realistic goal, it would be critical to consult with other
core designers and developers on the approach taken for every major
decision. For this reason, I'm wondering if it would make sense to try
approaching this project like a "feature plugin" project. Many current
feature plugin projects have only one primary developer, so the requirement
of having only one person coding might not be as restrictive as it seems.
One of the most important aspects of the feature plugin process is having a
group of interested people providing feedback and direction throughout
development. Logistically, I would propose holding weekly meetings/office
hours for the project where anyone interested can discuss it, to supplement
the role of the mentor for broader UI/UX feedback.


Please let me know if you have any feedback about the process I've proposed
here, as well as the concept of this project in general.


Thank you for your time.


Nick Halsey

http://celloexpressions.com/
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers