[gimp-web-devel/pat/bootstrap] Issue #5: porting wiki/WGO_Redesign-20161025045930-show.txt from wiki.

[Jehan <jehanp src gnome org>]

commit 3a08264fc5349152049f0477e5aa4294c9eab455
Author: Jehan <jehan girinstud io>
Date:   Sun Sep 11 18:11:31 2022 +0200

    Issue #5: porting wiki/WGO_Redesign-20161025045930-show.txt from wiki.
    
    Though it looks like a "finished" project", I think it's more of a
    "constant project", as we are constantly improving and redesigning the
    main website. For instance, we are also planning a move from Pelican to
    Hugo soonish. Also there are a lot of projects that we still want to
    happen, like showing more community news and events for instance.
    
    This is why, additionally to reformating in markdown, I renamed this
    page to "Contributing to the main website (www.gimp.org)". The contents
    stayed as-is for now, but eventually we should simply udpate this page
    to listing the current website state and where we want it to go next, to
    help new contributors to participate.
    Like a roadmap, but for the website!

 content/core/WGO/_index.md | 219 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 219 insertions(+)
---
diff --git a/content/core/WGO/_index.md b/content/core/WGO/_index.md
new file mode 100644
index 0000000..0122504
--- /dev/null
+++ b/content/core/WGO/_index.md
@@ -0,0 +1,219 @@
+---
+title: "Contributing to the main website (www.gimp.org)"
+Author: "GIMP team"
+Date: 2016-10-25
+---
+
+## 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](https://leivaburto.github.io/gimp-web-revamp/).
+
+### 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.
+
+* Possibly having role-based permissions against different areas of a git repository (admin, presentation, 
content, tutorials, news, etc...) ([git sub-modules](http://www.git-scm.com/book/en/v2/Git-Tools-Submodules) 
were mentioned as a way to manage this).
+* The proposed idea is to separate WGO content into more user-friendly discrete pieces, such as individual 
[Markdown](http://daringfireball.net/projects/markdown/) text files.
+* These text files (+assets) would then be passed through a processor to be turned into static HTML assets.
+* 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](http://www.git-scm.com/book/en/v2/Git-Tools-Submodules) as a means for segregating 
content/admin/presentation from each other within a repository.
+
+I (PatDavid) 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":
+
+```html
+<!--#include virtual="/includes/wgo-xhtml-init.xhtml" -->
+<title>GIMP - GIMP Quickies</title>
+<link href="styles.css" rel="stylesheet" type="text/css"/>
+<!--#include virtual="/includes/wgo-look-feel.xhtml" -->
+<!--#include virtual="/includes/wgo-page-init.xhtml" -->
+
+<h1>GIMP Quickies</h1>
+
+<h2>Intention</h2>
+
+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:
+
+* <a href="#scale">Changing the Size (Dimensions) of an Image (Scale)</a>
+* <a href="#compress">Changing the Size (Filesize) of a JPEG</a>
+* <a href="#crop">Crop an Image</a>
+* <a href="#transform">Rotate or Flip an Image</a>
+```
+
+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:
+
+```markdown
+---
+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:
+
+* [the Size (Dimensions) of an Image (Scale)](Changing)(#scale)
+* [the Size (Filesize) of a JPEG](Changing)(#compress)
+* [an Image](Crop)(#crop)
+* [or Flip an Image](Rotate)(#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](http://adamkaplan.me/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:
+
+# News Entry
+# 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](http://www.gimp.org/) 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
+  * User Manual (''see below'')
+  * Tutorials
+  * Books
+  * FAQ
+* 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):
+
+* The project name.  Main branding.  (GIMP - The GNU Image Manipulation Program).
+* How do I get it (Download).
+* What is it (The Free &amp; Open Source Image Editor).
+* How do I use it (tutorials/docs).
+* News
+* Get Involved
+* Donate
+
+Feel free to re-order these or suggest changes as needed!
+
+These are some ideas I (Patdavid) 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
+  * 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
+* 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
+