Felix Arntz 10:17 pm on January 17, 2018
Tags: , ,   

PHP Meeting Recap – January 15th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

After Servehappy had been officially approved as a feature project for WordPress in the past week's dev chat, the agenda of the meeting was to plan how to proceed further for the information and education page, which will be the first milestone of the project. Here are the discussion results:

  • It is still unclear whether the page will be a subpage of some existing wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ page or whether it will be a completely separate site with distinct domain. However, in terms of layout and design, it will not need to integrate with the common wordpress.org look, to have most flexibility in terms of UXUX User experience.
  • The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. adminadmin (and super admin) notice will initially only be put into the latest WordPress release, but it may be worth backporting it so that users of older versions are also informed.
  • Regarding the .org infrastructure integration and branding, it was decided to go with a completely separate design for the page. It should somehow indicate that it is an official WordPress project, but very subtly, for example with a link at the bottom of the page. The idea is that the page may at some point evolve to a collaborative project that may be helpful for other OSS on the web as well.
  • The rest of the discussion revolved around layout and design brainstorming (read more below).

Call for Designers

As we have a full draft of the page content in place, the primary goal at this point is to come up with a solid layout and design. Some initial thoughts were discussed during this meeting, but eventually, none of the team members is a designer or has significant UX experience. We would like to ask the #design team for help on this invite you to join our meeting next Monday to proceed with a more sophisticated discussion. @karmatosed furthermore plans to have a segment on the topic in tomorrow's design team meeting. We'd be happy to have you onboard!

To get started, here are some of the thoughts and questions we came up with:

  • An initial mockup can be found in the project's roadmap post.
  • Are accordion elements the right UIUI User interface component to use? No clear opinion on that, but there was agreement on that at least the initial one should be open.
  • Would having a floating sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. with the headings and inline navigation be useful? We generally didn't think so since we considered it something that devs are mostly used to, while are audience are non-technical users, and it may overwhelm users when they immediately see the amount of content there is regarding this topic. But it's still a possibility worth thinking through.
  • Instead of an actual sidebar, there could be small asides displayed here and there, with some of the content in the draft text already being designated for such.
  • An alternative idea was some kind of slideshow, with one slide per section. There could be a heading and one or two brief catchy sentences to arouse interest, and then a toggle to expand more details. A click on a button or scrolling could lead to the next slide / section. This approach may easily have accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) issues though if not done right. It would also need to be considered how to access specific sections quickly without being required to run through the previous slides first.
  • Maybe experimenting with different versions and doing user testing would work. This could happen at WordCamps and other events, although we need to be careful to keep in mind that the target audience are non-technical site owners, many of which probably do not attend such events.
  • The most significant question for us seemed to be whether the page should display all content at once or rather break it down into smaller pieces one by one.

We are hoping to get some more solid results in collaboration with the design team. If you think these ideas are terrible, please throw them away. All of us are developers, and that is why we need your help!

Next Meeting

The next meeting will take place on Monday, January 22nd, 2018, 16:00 UTC as always in #core-php.  The agenda will be to further discuss layout and design, hopefully with some members of the design team presents or maybe already results from their meeting. See you next week!

#core-php, #php, #summary