Ant Smith
donate to Ant Smith Print

Articles

My Website Framework - Part 2: Site Config, Structure And Look

The previous article covered a lot of ground in describing how to manage content for the different types of sections that a site based on this framework can have, but did so based on the example of my own website. Here I will explain how the framework can be configured to the needs of different sites. We need to cover:
  • Site identity
  • Site Structure
  • Site Look

Site Identity

Clearly the framework puts a big title at the top of every page and you will want your website to have a different title to mine! But there are other aspects to the 'identity' of the website that you will want to change. Some (like the title) are visible and obvious, other aspects are behind the scenes and help your site to have a unique identity in the eyes of the various cyberbots that we live with these days.
Obviously the 'domain URL' (in my case www.antsmith.net) has a big impact on your site's identity - but that is a matter between yourself and the internet directories (e.g. your domain registration provider). The framework has no influence over this!
There are 8 identity characteristics that the framework requires:
  • Site Name: the big title you see atop every page
  • Informal Name: this is used where we need to 'self-refer' (e.g. in the page footer when inviting folk to contact, and in metadata when citing 'Author')
  • Twitter Handle: So visitors can connect on twitter, and so we can show your twitter feed on a promo page
  • Donate Account: Connects the Donate button to a PayPal account
  • Donate Name: A more formal name associated with the Donate button (as Alt Text) so that people are very certain just who they are donating to
  • Site e-mail: so that contacts from the site can be sent to you
  • A Google Analytics unique tag: So you can see what traffic visits your site
  • A Facebook 'app id': So your site can use the integrated facebook services (like and comment)

Most of this is pretty self explanatory.

If you don't want to offer people the opportunity to donate then set those identity values to nothing ('');

If you don't want to track visitor stats (or just can't work out how to get a google analytics tracking-id then again just leave it empty ('')

Since you're using this framework it is reasonable to leave the Facebook App-Id at it's default value (it IS the same app!). But if you are a Facebook registered developer and do have your own App-Id feel free to use that here instead.

Lovely, yeah? But how are these settings made?

You should take a copy of the file 'site-config.php' from the sub-directory 'root-files' of the framework folder and store this in the root (top level) directory of your website. You can then edit it using any text file editor (technically it's a PHP script file, but script files are just text). The first few lines of that file look like this (we'll look at the rest of the file later):
<?php 

$GLOBALS ['TWITTER_HANDLE'] = 'antsmithpoet';
$GLOBALS ['SITE_NAME'] = 'Ant Smith';
$GLOBALS ['INFORMAL_NAME'] = 'Ant';
$GLOBALS ['DONATE_NAME'] = 'Ant Smith';
$GLOBALS ['DONATE_ACCOUNT'] = 'TheGameCat';
$GLOBALS ['SITE_EMAIL'] = 'enquiries@antsmith.net';
$GLOBALS ['FB_APP_ID'] = '131687593562617';
$GLOBALS ['G_ANALYTICS'] = 'UA-113346480-1';
...

Hopefully it makes immediate sense. You change the values on the right-hand side of the equals signs (the left-hand side indicates what it is you're changing). Make sure to keep the single-quotation marks and the semi-colons. Don't be using any other single quotation marks (or apostrophes) in the values you supply - it will screw the file up. (There are work-arounds if you want an apostrophe, just go and learn about PHP Strings if you really want such, although for the life of me, I can't imagine why you would).

You'll see there's a few other 'root-files' which you need too, infact everything in 'framework/root-files' needs copying up to your website's top directory so I'll explain them here:
  • .htaccess: You don't need to edit this, but you do need to have it. Basically it's the wiring that connects site URLs to the framework scripts that draw the pages.
  • favicon.ico:favicons appear in browser tabs and address bars, they are tiny little images (16px square) that allow your site to be visually recognised amongst a bunch of diffierent tabs you'll have open in a browser. You need to make your own and replace the default one. I made mine here: https://www.favicon-generator.org/
  • phpinfo.php and phpvars.php: You don't need to edit these, in fact you don't really have to have them, they just turnout handy sometimes...
  • site.css: We'll look at this file later, it allows you to set the look of the site (especially fonts and colours)
  • bespoke/:a directory that needs adding to the website top level directory. This is where PHP scripts that generate bespoke, one-off, pages have to live. You should make sure the directory exists at the root of your website even if you don't have any bespoke pages (yet).

As an aside, part of the framework's duty is to look at the addresses (URLs) that access the website so that it can decide how to draw the pages that the URLs are asking for. You'll get a better sense of how this is configured later (below), but essentially if a URL is asking for an item (or promo or photo) page the framework will get on with the job of drawing the page for you. If the framework doesn't understand how to draw the page it passes that duty on to a script in the 'bespoke' directory. This means your website isn't limited to just having the kinds of pages that the framework knows how to produce. For exmample, on my website I have a 'memes' section which is highly specialised, probably of little interest to anyone else, and so is not part of the framework. When a URL like 'www.antsmith.net/memes' or 'www.antsmith.net/memes/001' arrives the framework will assume there's a script file called 'memes.php' resident in the 'bespoke/' directory and it will pass the duty of drawing the page to that script.

Site Structure

The question of how you 'structure' a site concerns how all the masses of pages get divided up and grouped together so that the content is basically manageable, browsable, findable. If you just dump all of the contanet together it becomes really difficult to browse through it or find anything in particular. By dividing the content into sections everything gets easier - unless the sections simply make no sense, or if you just can't quite decide which section a given piece should sit in... It can be suprisingly difficult to decide what section a work belongs to. Even in simple alphabetical organisations it's hard to decide where a thing lives; think about the inconsistantcies that arise with 'The', should a title like 'The curious incident of the dog in the night' be catalogued under 'T', or should it appear under 'C' as 'Curious incident of the dog in the night, The'? (Structuring website content is pretty much the same job as organising a library, except we have more creative options with the epherma of digital assets than with the physical constraints of actual books!).

Structuring a site - Personas and Journeys

The key to structuring content is to understand how people will try to access it. That is, working out who's going to visit the website and why; why will people visit the site and what will they want from it. These might seem impossible questions, after all the cyberworld is just stuffed full of anonymous avatars! But actually, by considering the nature of the content these questions resolve quite quickly - as a creative artist or writer or photographer you already have a sense of who your work is meant for.

There's a lot of faddiness in the world of 'creative web design' and I'm sure there's them that will hate me or deride me for suggesting this - but as a way in to understanding the task of structuring your site it's worth creating a bunch of imaginary friends, or personas. Personas are pseudo-people you can understand (they're may be even based on people you know), and you can easily imagine why they come to visit your site and what they want from it. As an example, thinking about www.antsmith.net:

The site content consists of:
  • A whole bunch of poems. Some are high energy performance pieces with a viral renown, some are deeply introspective works published in underground or left-wing leaning outlets.
  • There's a bunch of lighter short fictions.
  • A whole host of photos, either documenting the poetry 'scene' or the world around us, or else standing as modern or pop-art works that have been seen on book covers and in photographic magazines.
  • There are major works that people will have seen in the news and
  • there are more scholastic considered articles.
In short, quie a hotch-potch...

So let's imagine up personas.

Lil' Johhny, he plays git-tar and jus' knows there's photos of his earnest brow lurking on my website.

Amelia, she digs flowers and she's sure she saw some beautiful shots that'd she'd love to be able to make herself in last week's Amateur photographer.

Ernst is just starting out as a performance poet and is keen to learn all he can by absorbing the work of others.
...

Okay, so naming your Personas is a little cheesy - but it does help in imagining their attitudes and behaviours. Lil' Johhny sure aint gonna wanna wade through a bunch of flower photos hoping to find a picture of his vizzog somewhere what with his low attention span and impulsive behaviours. Amelia, well she'd be quite horrified at some of the things she might see on the site. Ernst though, he could browse for hours if he wanders into the right place...

This is a very brief outline, but hopefully you start to see how we can create sections or tags aimed at what people want from the content.

This whole process should be fun and rewarding for a creator of artistic content because you're effectively writting the site narrative with characters and journeys. How many Personas do you need? How many different journeys might each of them take? How do you encourage a character to change paths? What do you need to give them to keep them motivated?

It all depends on the nature and quantity of the material - the more of that you have, the grander the story that the website can weave...

Configuring a Site Structure

Take a look at the rest of the 'site-config.php' file I introduced earlier. Here's the whole file:
<?php 


$GLOBALS ['TWITTER_HANDLE'] = 'antsmithpoet';
$GLOBALS ['SITE_NAME'] = 'Ant Smith';
$GLOBALS ['INFORMAL_NAME'] = 'Ant';
$GLOBALS ['DONATE_NAME'] = 'Ant Smith';
$GLOBALS ['DONATE_ACCOUNT'] = 'TheGameCat';
$GLOBALS ['SITE_EMAIL'] = 'enquiries@antsmith.net';
$GLOBALS ['FB_APP_ID'] = '131687593562617';
$GLOBALS ['G_ANALYTICS'] = 'UA-113346480-1';

$GLOBALS ['SITE_SECTIONS'] = array (
array (
'Name' => 'Home',
'Nav_Item' => true,
'URL_Part' => '',
'Branch' => 'home2017',
'Class_Ident' => 'home',
'Type' => 'promo',
'Title' => 'Creative Works',
'Description' => 'Fact and fiction, words and images; the creative works of Ant Smith - products'),
array (
'Name' => 'Poetry',
'Nav_Item' => true,
'URL_Part' => 'poetry',
'Branch' => 'poems2',
'Class_Ident' => 'poetry',
'Type' => 'item',
'Constrain' => false,
'Aggregate_Video' => false,
'Aggregate_Audio' => false,
'Tag_Short' => '12 lines',
'Tag_Long' => '48 lines',
'Tag_Video' => true,
'Tag_Audio' => true),
array (
'Name' => 'Photography',
'Nav_Item' => true,
'URL_Part' => 'photography',
'Branch' => 'photos2017',
'Class_Ident' => 'photography',
'Type' => 'photo',
'Constrain' => false ),
array (
'Name' => 'Projects',
'Nav_Item' => true,
'URL_Part' => 'projects',
'Branch' => 'projects2017',
'Class_Ident' => 'projects',
'Type' => 'promo',
'Title' => 'Projects',
'Description' => 'Fact and fiction, words and images; the creative works of Ant Smith - projects' ),
array (
'Name' => 'Stories',
'Nav_Item' => true,
'URL_Part' => 'stories',
'Branch' => 'stories2017',
'Class_Ident' => 'stories',
'Type' => 'item',
'Constrain' => false,
'Aggregate_Video' => false,
'Aggregate_Audio' => false,
'Tag_Short' => '800 words',
'Tag_Long' => '2000 words',
'Tag_Video' => true,
'Tag_Audio' => true ),
array (
'Name' => 'Memes',
'Nav_Item' => true,
'URL_Part' => 'memes',
'Branch' => 'memes2017',
'Class_Ident' => 'memes',
'Type' => 'bespoke' ),
array (
'Name' => 'Articles',
'Nav_Item' => true,
'URL_Part' => 'articles',
'Branch' => 'articles2017',
'Class_Ident' => 'articles',
'Type' => 'item',
'Constrain' => false,
'Aggregate_Video' => false,
'Aggregate_Audio' => false,
'Tag_Short' => '',
'Tag_Long' => '',
'Tag_Video' => true,
'Tag_Audio' => true ),
array (
'Name' => 'Video',
'Nav_Item' => true,
'URL_Part' => 'video',
'Branch' => 'video2017',
'Class_Ident' => 'video',
'Type' => 'item',
'Constrain' => false,
'Aggregate_Video' => true,
'Aggregate_Audio' => false,
'Tag_Short' => '',
'Tag_Long' => '',
'Tag_Video' => false,
'Tag_Audio' => false ),
array (
'Name' => 'Audio',
'Nav_Item' => true,
'URL_Part' => 'audio',
'Branch' => 'audio2017',
'Class_Ident' => 'audio',
'Type' => 'item',
'Constrain' => false,
'Aggregate_Video' => false,
'Aggregate_Audio' => true,
'Tag_Short' => '',
'Tag_Long' => '',
'Tag_Video' => false,
'Tag_Audio' => false ),
array (
'Name' => 'Buy',
'Nav_Item' => true,
'URL_Part' => 'products',
'Branch' => 'products2017',
'Class_Ident' => 'products',
'Type' => 'promo',
'Title' => 'Products',
'Description' => 'Fact and fiction, words and images; the creative works of Ant Smith - products' )
);


$GLOBALS ['DEBUG_STATE'] = false;
?>

We've already seen the top part earlier. The rest of the file is mostly a long 'array' called $GLOBALS ['SITE_SECTIONS'].

You can think of an 'array' as being a list in this context, and in fact SITE_SECTIONS is effectively a list of lists; it contains a list of configuration items for each section I've decided I want on the website. Not all of the sections have just the same list of configuration items as the other sections... that depends on the type of section we are configuring. And we already know that there are 4 different types of section: Promo, Photo, Item and Bespoke. So we need to understand that SITE_SECTIONS contains one list of configuration items for each section in the site. The order in which they appear defines the order of that they appear in the site menu. In fact you can see the terms that appear in the site menu are given by the 'Name' item that heads each of the individual section lists. Have a browse through.

So there are 10 lists of configuration items (one for each of the 10 sections in the website) of 4 different types (Promo, Photo, Item, Bespoke).

Although the specific list for each type of section differ, all sections have some configurations items in common, i.e. all sections contain configuration items for:
  • Name: How the section appears in the site menu (and also in metadata Titles etc...)
  • Nav_Item: Indicates if the site section should appear in the site menu
  • URL_Part: How the section appears in a website address (URL). Mostly this is very similar to 'Name' but note that 'Name' typical starts with an uppercase letter for a nicer display. Also note the 'URL_Part' and 'Name' don't have to be at all similar. The menu 'BUY' section relates to the 'www.ansmith.net/products' URL address.
  • 'Branch: Remember how in the last article I kept going on about the website section's content directory? Well, this is how that relationship is defined, how a section knows where to find its content.
  • Class_Ident: Okay I admit it, this is a super geeky term - it should make more sense later. Simply put this defines the style of the section in the same way as we used named styles to decide the trim colour that a static promo will take (in the previous article).
  • Type: Defines the type of the section (promo,photo,item or bespoke) and so defines the structure required in the associated content directory (Branch) as you'll remeber from the previous article. Also defining the set of additional configuration items required in this list, as detailed below.

As a quick aside, why did I decide to use such a different term in the site menu than I did in the URL for the last section on the site (the one being 'BUY' and the other being 'products')? This speaks to the implicit difference between the representations. The URL (where I use 'products') is primarily semantic machine language. It is important that URLs represent the nature of the information they point to so that machines understand how the content relates to everything else on the internet. This section of the site fundamentally presents 'products' so the URL for it uses the term 'products'. But, people think differently and the menu presentation is primarily designed for humans. The imperative 'BUY' is much more understandable by people than the more semantically correct term 'products'.

Note also how the Class_Idents and the URL_Parts all look the same in the values they take. This is just because we're loking at a first implementation where, for example, product pages have product type styling. Over time new styles will be developed (and probably given better names). They are actually fundamentally different things and it really means nothing that I've given them similar (or, er, identical) names just now!

Okay, so we've seen the common configuration items that have to be given for any section we define for the site. Lets look now at the additional configuration items each type of section require.

Promo Section Configuration Items
Web pages require some standard 'metadata' items so they can be adequately indexed by search engines and well represented by third parties when sharing. These standard items include a Title and a (typically short form) Description. For most pages the framework can work out a good title and description. Clearly the title of a photograph, or name of a collection or gallery makes for a good page title. And the title given to a poem or story etc can readilly be used as the page title. With regards description, for an item this will come from the supplied author's notes, or else (if there isn't an author's note) will come from the description of the associated collection (if any) or otherwise will be the first few lines of the item's main text file. Galleries have a descriptive text file, and photographs can have a description in a text file too, so a decent enough description can be worked out for those. Basically the framework does it's best to create really meaningful titles and descriptions for you.

When it comes to promo pages though there isn't any obvious way to automagically determine what makes a suitable title and description given the content of the page. So for Promo type sections you need to specify a suitable Title and Description.

Photo Section Configuration Items
Photo sections just need one more configuration item than the standard set. Constrain I'll describe this now since there's nothing else to say about Photo sections, and this relates to Item sections too, about which there's plenty to say!

The framework generates a hierarchy of pages, dependent upon the type of the section the pages belong to.

Promo sections generate but a single page, the page containing the defined promotions.

Item sections generate one page for each item in the section PLUS an overview page, for the case where a specific item isn't specified in the URL request.

Photo sections generate an overview page of all galleries in the section, collection pages for each collection in each gallery, and photo pages for each photo in each collection of each gallery.

Item pages therefore have a 2-level hierarchy (overview and items).
Photo pages have a 3-level hierarchy (galleries, collections, images).

Sometimes you will need to create a section with less content than is necessary to support the hierachies of the section. For example, you might have a category of photographs that are important enough to appear in their own section but for which it just doesn't make sense to define multiple galleries, it might not even make sense to split them into seperate collections - they might just be a flat grouping of images.

For a photosection that contains but one gallery (which maybe contains but one collection) it is awkward, in fact odd, to present a 'galleries overview' page when you'd be overviewing just one gallery.

To this end you can, in a site section, specify a link not just to the section but rather to a specific gallery in the section. If you define such a section as Constrained then from the gallery overview of collections the page will not include the 'UP' navigation element and so your visitors will not be taken to a galleries overview page that overviews but one gallery.

So if, for example, you have a content directory (photos) for a photo section that contains just the one gallery 'Gig Shots' perhaps with collections 'Sarf London' and 'Rest of the World' you won't want the website menu to point to the top of that section (since it's going to give you a page with just one gallery on it). So instead you point the SITE_SECTIONS entry directly at that gallery and you define the section as Constrained - so that the navigation up to the galleries overview is suppressed.

Which might look something like:
...

array (
'Name' => 'Gig Photos',
'Nav_Item' => true,
'URL_Part' => 'photos/gigs',
'Branch' => 'photos2019',
'Class_Ident' => 'photography',
'Type' => 'photo',
'Constrain' => true ),
...

In photo and item type sections you can 'deep-link' as far as you like. If the gigs gallery in this example only included one collection from Sarf London (because as a londoner you'd never really had the need to go anywhere else inthe world) then you could have used 'photos/gigs/sarf-london' as the URL_Part for your Gig Photos section.

The same is true for item type sections. If you have a collection of writings that are so important they deserve their own menu item you can point straight at it. If these exist in their own content directory you can mark the section as constrained and avoid all the extra navigation that an item section normally promotes.

You can also 'deep-link' in an unconstrained manner. If the 'thing' you're linking to exists inside a section which lots of other content you can jump straight to it from the website menu but still provide all the navigation around the section after arriving there.

In Summary:
  • Site sections allow for 'deep-linking'
  • 'Excessive' page hierarchy can be constrained for very focussed site sections

Bespoke Section Configuration Items
Since bespoke pages are by definition basically unknown to the framework (aside from what they're called, where they live, how their promotions are styled) you don't need to specify any additional configuration parameters here. The bespoke PHP script that implements the specific bespoke page has access to the SITE_SECTIONS definition and the global site configuration items - all discussed earlier. It can also make use of:
  • framework/pagetop.php: so that the bespoke page gets the same banner and site menu as any other page
  • framework/web-share.php: so that the bespoke page gets the same share, contact, comment and search facilties at the page end that any other page on the site gets.
  • framework/common-js.php: so that the bespoke page gets the same EU GDPR-regulation compliancy, google analytics tracking and Facebook integration facilities as any other page in the site
  • framework/image-handler.php, framework/image-sizer.php and framework/nsfw.jpg so that images in the bespoke page can behave like other images on the site
  • framework/web2017CommonCSS.css: so tha the bespoke page can inherit font and styling common to the rest of the site.

Yeah, so this is getting kinda technical - hopefully that's enough info for any PHP coder to create bespoke pages that fit well with the framework pages, and I shall say no more on that matter now...

Item Section Configuration Items
Item pages have the greatest number of additional configuration items. They allow for deep-linking from the website menu (as per photo type sections) and so also require the Constrain item. There is also a set of 4 true or false flags that need to be defined and 2 'counting' tags.

The six items specific to item sections are:

Tag_Short will automagically create a tag called 'Short'. It is intended for people who want to read flash fiction or short-form poetry. Items will be added to this tag if they are shorter than the limit specified by the configuration item's value. E.g. if Tag_Short is set to '12 lines' any item main text file containg 12 or fewer lines will be considered as a short item. The value of this tag is a number, followed by a space, followed by either 'lines' or 'words' (lowercase) - depending on how the counting is to be performed.

Tag_Long similar to the above, but intended for people who want to read something more immersive.

Tag_Video if the items in a section are primarily textual in nature (like poems, stories, articles...) and a lot of them have additional illustrating video you might want to automagically create a 'with video' tag; so that people can readily browse all poems that have a video (say).

Tag_Audio kind of like the above, but for audio!

Aggregate_Video if the items in a section are primarily videos (not words) then it doesn't make sense to automagically create a 'with video' tag (as in this section just about everything has video and the tag is no more useful than the section overview page that lists all items anyway). BUT the overview page only lists the videos in this section and the site visitor has expressely shown an interest in video by coming to this section. So it's useful to also offer them the opportunity to browse all the poems that have video aswell (or all the stories with video etc). This is a powerful feature wrt the site super-narrative as it encourages visitors to break-out of the section of immediate interest and pop-off to explore other parts of the site.

Aggregate_Audio you get it by now I should think...

Some Practical Concerns

Apart from the special 'Aggregate_Video' and 'Aggregate_Audio' options just described, the framework will also always aggregate tags when it can. So if two different site sections use the same tag the visitor will be given a 'see also...' link in the list of items in this section's tag. This encourages 'side-journeys' - to get people out of one section of the site and into another one. We sectionalise the content to meet the needs and expectations of visitors, but in so doing we create barriers to their opportunity to experience the full scope of works. It's a trade-off for sure. Tags only group items in a given section, but if another section uses the same tag name, there is opportunity presented to jump sideways into that other section.

PLEASE NOTE - Regarding entries in th site-config.php file: All configuration items are either TEXT or FLAGS. TEXT configuration items must be enclosed in single quotes. FLAG configuration items must be set to true or false (lowercase and without quotes. Also take note of the use of commas to seperate items (the last item in a list doesn't need a comma!). Missed quotation marks and forgotten commas will be the source of most trouble when editing the site-config file.

Debug: there's a final entry in the site-config file we haven't discussed. The line
$GLOBALS['DEBUG_STATE']   = false;

You can leave this well alone. IF you find you're in dire trouble, just not understanding why the site isn't behaving itself with respect to content you've upload, you can set this value to true and the framework will dump out heaps upon heaps of information about what it is thinking, which can help in working out what's going wrong. Mostly you don't want it to do that...

Naming Issues
Top-level site sections should use either mass nouns (e.g. Poetry) or plural nouns (e.g. Poems). By definition sections clump a bunch of content together so the reference to them (their name) should not be singular in nature. 'Home' of course is a special case, live with it...

Also, do not name any item, item collection, item tag, photo gallery, photo collection, or photo, 'collection' or 'tag'. These two words have a special meaning in the framework's underlying structure and you will have trouble if you try and create a poem called 'tag' - sorry, that's just how it is. Anyway the world has enough poems called 'tag' (does it really? I'm gonna say 'yes').

You might wonder why I've used different naming for a section's content directory ('Branch') and its associated 'URL_Part' - e.g. the 'stories' site section uses the content directory 'stories2017'. This is by deliberate design. URLs are (or should be) immortal, once published never lost. This is the very spirit of the internet, one of it's great strengths over a real-world society with its capitalist predeliction for putting books out of print and its history of burning libraries down. We do though constantly, for all kinds of reasons, end up moving the underlying disk-based files around - maybe switching to a backup or preparing for a major site update. So these two things are best kept distinct. It also greatly helps when rewiring a URL to a disk structure - if URLs never map directly to an existing disk-based item it's easier to see that they should be routed through to the scripting engine. Anyway, the way the framework behaves, you see some odd stuff if you happen to use the same names in URLs as you do in the underlying disk structure. Take my word for it (maybe a better programmer has the delight of scoffing at this moment, m'eh I at least understand 'humility').

Finally, on the practical dimension, I make significant use of HTML in the various text files when needed - Weird Scenes EP is an extreme example. Mostly I use it for adding supplemental images (an item only gets one illustrating image), as I did in the story What Time Is It Mr Wolf. But note, images must be included with extra care. Here's an example of how an item's main text file might include an image from the sub-directory 'images' in the item's content directory:
<img src="./images/example-nsfw.jpg" alt="description of the image" width="600px">

When the framework finds an HTML img tag it wraps the image inside an additional HTML (and adds some extra attributes to the img tag) so that the image works with the NSFW filtering technique the site employs (and also offers the click/touch pop-up behaviour). The framework also replaces the relative reference ('./') in the src attribute with an absolute reference, so that once the text has become a part of the page's HTML everything hangs together. The important point is: DO ensure the entire image tag appears on a single line of its own, don't break it across lines in the text file and do not put other text on the same line.

Also note, because the image tag is re-made by the framework you can only use the attributes indicated (src, alt, width) - anything else you specify (like style or height) will be lost. But hey, at least images are consistent across the site! And you should provide an 'alt' description - this ensures that visually impaired visitors understand what the image is. Describe the image, so they too can appreciate the richness of the offering.

The framework also modifies the 'href' part of any embedded link to ensure everything hangs together. When putting '<a href=...' link tags into a text file keep the entire tag on one line and do not add extra spaces (especially around the '=' sign).

Site Look

The site.css file

There is a root-file called site.css. All framework pages include this and you can use it to override the default styling of the framework.

Fonts

The first part of the file imports the website's font from Google. They have a font directory at: https://fonts.google.com/. Type face plays an important role in creating a site identity.

Changing and Adding Styles

There is a section in this file called 'TYPE CLASSES'. If you want to change the colours that the pre-defined Class_Idents use that can be done here. Colours are defined in rgba values (red, green, blue and alpha/opacity). The W3C colour picker tool is helpful in choosing rgb values: https://www.w3schools.com/colors/colors_picker.asp.
The opacity is any value from 0.0 (transparent) to 1.0 (opaque).

If you want to create new Class_Idents copy one of these sections - but note these sections are relating the colours to the actual page display components; therefore you need to copy the right kind of section! E.g. to create a new styling for a promo page copy the entire 'projects' section. Then replace the word 'projects' with your new desired Class_Ident and then set the rgba values appropriately.

Download the framework


So you can download this framework for free here.


Or you could take a moment to value the efforts and hit the DONATE button at the top of the page first.


It kinda depends on what kind of a person you want to be...






Articles