WGO Redesign

From GIMP Developer Wiki
Jump to: navigation, search

Why?

The email from Cristobal on the Gimp-web list recently prompted this further discussion. His summary of work and ideas were documented on this page.


Assumptions

  • We (the royal 'We') could benefit from having more content on WGO, in particular tutorials.
  • Lowering the barrier-to-entry can help entice users to generate new content.
  • A new facelift can't hurt from a PR standpoint.


Benefits

There are a few possible benefits from conducting a redesign now:

  • Better organization of content
If the content organization is approached as described below.
  • Modern Look
  • A chance to consider usability and ease of access for users (and to improve it)
  • Lowering the barrier to entry for new contributors/contributions.
  • Responsive Design

Summary

From an architecture standpoint, the general idea is to separate content from presentation. This is already how the current site exists, though the implementation is a little clunky.

  1. Possibly having role-based permissions against different areas of a git repository (admin, presentation, content, tutorials, news, etc...) (git sub-modules were mentioned as a way to manage this).
  2. The proposed idea is to separate WGO content into more user-friendly discrete pieces, such as individual Markdown text files.
  3. These text files (+assets) would then be passed through a processor to be turned into static HTML assets.
  4. These static HTML assets would then be served to users.

Overall, the approach from Cristobal considers the problem one of creating Application/Content/Presentation layers.


Application - Role based access (git submodules)

There was originally proposed utilizing Git submodules as a means for segregating content/admin/presentation from each other within a repository.

I (Pat David) am not familiar enough with Git to speak to this, and could at some point use some input on the idea. As near as I can tell, the idea is that sub-folders of a Git project can be designated as sub-modules from other projects?

It appears that this may be something that can be separately addressed later in the process of implementing a new site.


Content

The content for the website can be decoupled from the presentation layer. One method of doing this is to house all of the content in an easy-to-use plain text format such as Markdown (or some combination of Markdown + html).

A benefit of separating the content from the presentation layer is portability of the content. It becomes easier later on to re-adapt the content layer to a new presentation layer as needed. This also helps to lower the barrier to entry, as any given piece of content is a self-contained folder of plain-text markdown (or html), as well as the associated assets needed. This is already similar to what is being done on WGO, but even further removing the presentation information as well.

Consider, for example, this snippet from the tutorial "GIMP Quickies":

<!--#include virtual="/includes/wgo-xhtml-init.xhtml" -->
<title>GIMP - GIMP Quickies</title>
<link rel="stylesheet" type="text/css" href="styles.css" />
<!--#include virtual="/includes/wgo-look-feel.xhtml" -->
<!--#include virtual="/includes/wgo-page-init.xhtml" -->

<h1>GIMP Quickies</h1>

<h2>Intention</h2>

<p>
So you installed GIMP on your computer, congratulations!  
GIMP is a very powerful image manipulation software, but don’t let that intimidate you.  
Even if you don’t have time to learn advanced computer graphics, GIMP can still be a very useful and handy tool for quick image modifications.
</p>
<p>
It is my hope that these few examples will help to solve those small, quick modifications that you may need to apply to an image.  
Hopefully this will lead to learning even more powerful image editing capabilities that GIMP is capable of as well.
</p>
<p>
For quick access, these are the four main points I’ll cover in this quick tutorial:
</p>
<ul>
        <li><a href="#scale">Changing the Size (Dimensions) of an Image (Scale)</a></li>
        <li><a href="#compress">Changing the Size (Filesize) of a JPEG</a></li>
        <li><a href="#crop">Crop an Image</a></li>
        <li><a href="#transform">Rotate or Flip an Image</a></li>
</ul>

There are still some Server Side Include statements, as well as having to build out a valid HTML document while writing. This may cause extra burden on someone willing to contribute new content, but not comfortable with writing directly to HTML.

This same content, represented as Markdown, would look like this:

---
title: "Gimp Quickies"
author: "Pat David"
...
collection: tutorial
---

# GIMP Quickies

## Intention

So you installed GIMP on your computer, congratulations!  
GIMP is a very powerful image manipulation software, but don’t let that intimidate you.  
Even if you don’t have time to learn advanced computer graphics, GIMP can still be a very useful and handy tool for quick image modifications.

It is my hope that these few examples will help to solve those small, quick modifications that you may need to apply to an image.  
Hopefully this will lead to learning even more powerful image editing capabilities that GIMP is capable of as well.

For quick access, these are the four main points I’ll cover in this quick tutorial:

* [Changing the Size (Dimensions) of an Image (Scale)](#scale)
* [Changing the Size (Filesize) of a JPEG](#compress)
* [Crop an Image](#crop)
* [Rotate or Flip an Image](#transform)



Presentation

With the content abstracted further to plain text files, the presentation data for WGO can be managed separately from the content. This allows not only parallel workflows but the possibility of drastic modification to the presentation layer without any undue burden on the content creators.

The presentation layer is also something that is usually defined in terms of the static site generation (but can be modified/customized as needed).

For pixls.us, I had used a bit of Adam Kaplan's Grid as a basis for extending the site. This has the benefit of being a responsive design with various possible screen sizes accounted for in @media CSS. This is not a requirement, of course, but if doing a redesign we might as well consider responsive and mobile-first options.

Requirements

Current Site

A look at the current site and types of pages that a redesign would need to support. Looking at the WGO right now shows a very simple breakdown of content type into two main types:

  1. News Entry
  2. Static Pages

These are the primary page types we can find.

News Entry/Article Post

News entries are relatively simple, as they've primarily been the snippets of updates shown in reverse chron. order on the main WGO page.

Static Pages

The rest of the pages can be considered simple static pages. These include:

  • Screenshots
  • Features
  • Downloads
  • Documentation
    • User Manual (see below)
    • Tutorials
    • Books
    • FAQ
  • Get Involved
  • Donations

There are a few other pages that follow the same conventions as a simple static page.

User Manual The user manual is a separately compiled project, right? In this case we can work with the devs on that aspect to make sure that the new static build system has what it needs in place to support this.

It would also be in our best interests to make sure that the URL's remain the same as they've always been, or to carry the correct 301 redirects as needed to avoid losing any indexing-sauce that has been built up.

Suggestions

Importance

Talking with schumaml, a list of things that are most important to users visiting the page (imo):

  1. The project name. Main branding. (GIMP - The GNU Image Manipulation Program).
  2. How do I get it (Download).
  3. What is it (The Free & Open Source Image Editor).
  4. How do I use it (tutorials/docs).
  5. News
  6. Get Involved
  7. Donate

Feel free to re-order these or suggest changes as needed!


These are some ideas I (Patdavid (talk)) am considering moving forward with:

  • The main page should serve these distinct purposes (roughly in order of importance):
    • Clearly state the name of the project
    • Clearly state the description of the project
    • Clearly provide a means for getting the software
    • Display recent news items/articles/blog posts
    • Describe the program in high-level
Basically, anyone landing on the main page should have no doubt what they are looking at, what the program is for, and how to get it.
  • Try to keep the existing URL structure intact as much as possible.
The only way it might not be the same going forward could be due to removal of some pages that could be considered extraneous.
Even then, the pages should probably still exist to not break anything (just soft-remove them by no longer linking to them from anywhere).
  • Consolidate page information onto a single page as appropriate.
For example Screenshots and Features might be better off having their information be presented/duplicated onto the main page.

Pelican