The Sheen Project: Deciding on the contents (December 13, 2023)

Identifying the what.

So far, the inspiration to build this website has stemmed from a very broad desire to simply communicate with ... you, and anyone else that may stumble along it via a web search, or however they happen to find it.

With that criteria in mind, it would take some kind of devine inspiration to sit down and actually implement something that satisfies the urge. Logical and simple solutions to this could be anything, from just writing an email or open a social media account. But that is not what I want to do, I like to create.

So to get on with identifying what to produce, I need to be specific about what I want. In order to commune with other interested people about various topics, I've identified the following things I'd like my webiste to support:

• Home Page: Welcome and a single entry point to the other stuff.
• Projects: Keep records and document a project's progress.
• Blog: Talk about projects, ideas and the like.
• Reviews: Share my experience with such things as tutorials, blogs and publicly available resources. that I've found useful.
• Forum: Engage with others sharing their own ideas and experiences on related topics.
• Login System: For access to website administrative tasks and for guests (maybe memberships?) to submit posts to a forum etc.
• GIT Repository: A centralised place for version control and sharing.
• Contact: Webform/email (some kind of) contact method for a webmaster, author, etc.
• Bug Reports: For software projects and the website itself.
• Help: FAQ, website orientation and questions.

I may think of other things I'd like to include, and it's possible I may wish to remove something, so the priority would be to make the above modular and keep them independant from the others.

Brief description of website elements

I don't yet know the exact form the above modules will take, but a basic mudmap will provide a starting point to build upon.

General Webiste Page Template

Header

Will display the module, section and page being displayed.

There may be a logo designed at sometime. If so, that will also be displayed here.

Navigation Bar

Contains the links to the main modules the website publishes for general visitors, in one narrow strip near the top of the page.

This navbar will remain visible as the page scrolls so a visitor can opt to navigate to another area at any time, unhindered by a scrolled page.

Scrollong was considered to be limited to the Page Payload area only, for the following reasons:

• To keep the navbar in view at all times.
• To keep the footer information links in view at all times.
• Attempt to give the website as a whole a look and feel of unifomity, by making page navigation feel as though it was just updating the information requested by a navigation link in the Page Payload area only.

The second option was considering a sticky navbar (see w3schools: How TO - Sticky/Affix Navbar) to keep it visible when scrolling.

The arguments for this option are:

• Vertical page space is a high priority asset on modern letterbox style monitors, especially with laptops (which can be common development hardware, especially among students). Minimising unnecessary vertical space should then be a priority.
• The header and footer are lower priorites for keeping in view at all times and take significantly more vertical space than the navbar.
• For the cost of a samll amount of JavaScript and styling, the consumption of vertical space after scrolling can be limited to a relatively narrow navigation bar.

Of the two scrolling options discussed, the second (sticky navbar will be the one to proceed with.

Page Payload

This is only a conceptual viewport that describes the remainding display space after the Header, Navigation Bar and Footer have been rendered. In essence it is just the web page minus the business end of things above and below it.

For example, if the link Blog was clicked in the navbar, this is where you would be reading the blog post, viewing any images and whatever else relates to a blog, such as links to the next and previous blogs, filters, and a blog search tool. To repeat, it isn't anything special that needs to be developed. It is the web page, ignoring the header, navbar and footer.

Footer

Similar to most other websites. The footer will contain links to information about the website, publisher, etc. rather than links to the publication content.

Preliminary Page Payload Concepts for Each Module

Since the Header, Navigation Bar and Footer are common to all website published pages, they can be included/generated into each page automatically with just a few modifications for things such as:

• Excluding the current page from the navbar links.
• Altering the header text to reflect the currently viewed page.

Otherwise all page's content, displaying its specific purpose, is what is visually seen in the Page Payload area. Remember that the Page Payload is only a conceptual region of the display. In actuality, it is just the space left after the Header, Navigation Bar and Footer have been displayed at the top and bottom. For each module, a preliminary structure for the contents of its Page Payload is described below:

Home Page

The home page really doesn't have any boundaries yet. It will be the landing page for this website and attmept to give visitors an overall understanding of what they can expect to find on The Sheen Project and how to find it (hopefully in an effortless and pleasing way).

Since the home page will be where all the other stuff on the website comes together in one place, without all the other stuff already defined it is difficult to define the nucleus of it all.

The design of the home page is probably the most volatile of them all. It's main funtion of summarising and providing a central interface to everything should perform two high priority tasks:

1. Give new visitors the direction they need to quickly become confident navigating the website and finding what they came for.
2. Keep return visitors up to date across the board of website features.

Some ideas that came to mind so far are:

• A very brief description of what The Sheen Project is and what can be found.
• Will be keeping this short though (as in two short sentences (banner or quote like) as the maximum, ideally one short quip). It can be useful for new visitors but also just a big block of words that is completely ignored. If it detracts from fluid usage and appeal, then I'd prefer it in an About page, where someone who actually wants to read it can easily find it.
• A centralised navigation graph that visually depicts a conceptual map of the website itself. Each node of the graph representing a place to visit, along with a visually suggestive icon, image or stylised title.
• The point is to enable a visualisation of all the places to go in the website and permit instant navigation to any place of choice.
• Possibly to complement that functionality, the navbar menus ought to have dropdowns for submenus, to afford the same navigational flexibility after leaving the home page.
• If the website's size becomes too large to make such a layout impractical, then consider an alternative, if not simplifying to a more generic structure.
• For web pages that have regular updates and postings, such as a blog or forum, display the post name and date (if within a given time such as n days to limit unnecessary clutter of aged topics) in proximity with hosted page/location.
• Another alternative is to display the number of new posts/articles etc. since the last login/notification (for someone currently logged in).

The following sketch is an illustration of what a sample Home Page layout.

Projects

Projects will be categorised to reflect the nature of their development and use. Depending on the number of projects, categories may have subcategories. Examples could be:

• Programming
• Web Development
• Utilities
• Electronics
• Computer Hardware
• Multimedia
• Video
• Audio
• Homemaking
• Repairs
• Garden
• Writing

Categories and projects should be searchable, with links to categories, subcategories and their projects. Filters will be available to quickly search for project posts by name, category, date and keywords.

A distinct posting structure for projects has still not been identified, so it still wide open to interpretation, except for having the following attributes:

• Allow for an article style post which may include headings, lists, tables, diagrams, images, sound files, videos etc.
• Have a place for reader comments and feedback.

This post you are reading now is an example of a project article.

Note: I'm still considering whether or not Projects will also include a Side Bar similar to the following Blog, Reviews and Forum.

Blog

Blogs will also be categorised in a similar way as intended for the projects. Instead of listing the possible categories, as above for Projects, it would be a good idea to take note of the similarities and repetition.

In the currently identified things this website aims to provide, the same, or at least similar, categories will relate to:

• Projects
• Blogs
• Forum
• Reviews

So instead of repeating the intended categories for each, just add a table to the requirements list for a database. So, note to self:

Add a table to the site admin database for the project, blog, etc. categories.

The blog page area will contain:

• Blog article

  which may also contain such things as:

• bitmaps (images, photos etc.)
• vector graphics (graphs, charts, diagrams etc.)
• multimedia (videos, sound files, animations etc.)
• Comments
• Side bar

  which will contain possible things such as:

• Next and Prev navigation links.
• Blog listing hierarchy.
• Filter and sorting options for the blog listings hierarchy.
• Blog author (with link to the author's About page).

Reviews

Reviews will be on any arbitray thing of interest, but will also have some kind of relationship with other things present elsewhere on the website. There will be the ability for visitors to comment on the reviews and to search and filter them. So, much the same as the above Blog layout, but with a Review for content instead of a Blog.

Hence, again repitition of content for Comments and Side Bar.

Forum

The forum will also have categories (topics) and a Side Bar to help search and filter through them, but it will not have Comments. What's to comment on? All that sort of stuff goes directly into the forum itself.

Login System

Login is a simple page with a form for visitors to enter their login name and password. If the page comes from a clicked register link then the title will show Register.

If the page comes from a clicked login link or previous failed attempt, the title will show Login.

If the page comes from a failed login attempt, the otherwise hidden Register checkbox will also be shown to give them the option of re-entering a name and password or registering for new ones.

Once login is successful, navigation will be directed to the page where the login link was selected.

Note: This page may also be shown as a popup form instead of directing to a dedicated page, and then back to the previous page that called it. It may be a neater navigation flow that way, without taking away a page the reader may actually not want to leave. For eg. if logging in to comment on a post, it would be neater if the page with the post didn't disapear just for them to login.

GIT Repository

A GIT repository is going to be available on the webiste, but it is still undecided how visitors will be able to access or browse it.

Comments on a GIT repository doesn't make too much sense, so no comment section will be available. Similarly with a Side Bar. What benefit would it have for a GIT repository?

So for now, GIT is a blank canvas, left for future design when other core services are already available. It should have a graphical interface so visitors aren't forced into using remote pull and push requests, but for now it is just service that will be included.

Contact

A page dedicated to providing methods for visitors to contact The Sheen Project. At the moment, plans are to include:

Webmaster
• Issues regarding the operation and administration of the website itself.
Feedback
• To provide suggestions, compliments, complaints etc. about the website and its contents.
Suggestions
• To recommend an idea that a visitor may like added, reviewed etc.
Bug Reports
• Bug reporting was going to have its own section, but probably could be included in with the contacts. It is a place for visitors to report issues, such as errors and ommissions, with software related projects and the website itself.
General Contact
• For contacting The Sheen Project about any other things that don't fit the above scenarios.

The principle method of contact would be a web form with a dropdown box to select the type of contact, or contact person. Then there would be input forms to supply the content and details needed to submit the contact.

This is a lower priority functionality compared to making content available, so will be dealt with in more detail some time in the future.

Whether or not to publish contact email addresses is still under consideration. If so, it would likely only be available to registered users. The full contact suite would still be available through the online form.

Help

Display a FAQ for instant answers to common questions and maybe a form to ask personalised questions that are emailed to a 'help' email address if the FAQ dowsn't cover the issue.

Both the FAQ and direct question form should allow for selecting a category that the question falls under.

This will change quite a bit, espicially when it comes to identifying the contents of the FAQ.