web development

Standards for Conceptual Data Models

It is to state the obvious that data is about things. But I am often finding that I have to ask myself precisely which things?

The creation of data models is an integral part of software engineering. They are used, particularly in database design, to understand and map out the structure and characteristics of the data you are working with. Traditionally there are three types of data models that can be applied to a given system; each building on the previous one and increasing in complexity. These are:

  • the conceptual data model,
  • the logical data model,
  • the physical data model.

The conceptual data model is the highest-level description of the data used in a given system and is the one most closely concerned with matching the data to the actual things that the system is concerned with. This data model will identify concepts and the relationships between them. For example, in a business accounting system the model may identify that the customer (the first concept) has one or more (the relationship) invoices (the second concept).

When doing WordPress development I am often attempting to develop a conceptual data model of the needs of a particular website so that I can determine how many custom post types I need to create. In my current work with open data I find that I have the need to clearly conceptualise the actual thing that any new set of data is about in order to create an appropriate schema for it. I think I have got pretty good at this type of modelling and have become convinced of its benefits as a problem solving tool beyond the realm of building databases.

I have also become aware that because the things that software and web applications are working with are often the same or similar — people, events, transactions, content items and so on — this opens up the opportunity for people and organisations to work with shared conceptual models and even for the development of common standards.

This view was reinforced by the presentation given by Paul Davidson, Director of Standards for iStandUK, that I saw at the recent Making Data Standards Work event.

There are three aspects of this that interest me and that I would like to explore a bit further:

Obviously shared conceptual data models help to underpin the development of open data. If you want to create data schemas that enable the widest possible sharing of data then it helps if they are describing data that relates to clear commonly understood concepts.

Thinking about common conceptual data models should also help me to improve my web development work. Obviously when trying to conform to web standards and best practice I am, at a number of levels of abstraction, already working to widely shared conceptual data models. The semantics of HTML5 for example. But I think I can take this further. Given that I am regularly making use of similar post types and page elements across different projects, I should be able to create a standardised conceptual model for Grit & Oyster and use that as a framework to help me write better and more efficient code.

Software engineering will primarily think about conceptual data models as they apply to individual systems. Common standards, such as web standards, will require conceptual data models that are global or generic. But there is the opportunity for standardisation of conceptual data models at the level of the organisation which could be hugely beneficial.

I have come across a number of initiatives that attempt to develop standard models or are in part dependent upon them. These I will document below (and add to when I find new ones):-

Schema.org

The schema.org project to develop vocabularies for structured data on the internet, because of the broadness of its objective, has created an implicit conceptual data model, or more accurately a number of interlinked models, which I think acts as a good starting point for a developing models for web applications.

You can see the full schema.org hierarchy of types (of things) on their website but the top layer is as follows:

  • Thing
    • Action
    • Creative Work
    • Event
    • Intangible
    • Organization
    • Person
    • Place

Smart City Concept Model

As part of the standards strategy for smart cities in the UK promoted by the Department for Business Innovation and Skills (BIS) the BSI (the British Standards Institution) has developed the Smart City Concept Model. This standard (PAS182) defines a series of concepts that describe the things that are typically contained in city data.

“The model is relevant where many ORGANISATIONs provide SERVICEs to many COMMUNITYs within a PLACE.”

Local Government Business Model

The Local Government Association (LGA) in the UK has developed the Local Government Business Model (LGBM). This is an attempt to define the elements of public sector service delivery provided by local government.

The Local Government Business Model
The Local Government Business Model

The model is fleshed out with a number of standardised and interlinked lists that can be found on the esd standards website.

 

Loading template files in plugins

I’ve been working on a project where I wanted to include a template file to handle the display of a particular WordPress custom post type. However, I wanted this template to be included in the plugin that created the custom post type and not in the theme. The plugin adds the post type to one site, and one site only, within a multisite network, so I didn’t want to clutter up the folder of the theme which is used on other sites that don’t require the plugin.

So I looked for a way to do this and discovered the role of template loaders within plugins. Including a template loader in your plugin allows you to associate a template file in your plugins folder with a filter hook or a shortcode. But the great advantage is that it replicates the behaviour of the get_template_part() function — which means you can override the default plugin template file with a custom file in a child or parent theme. (Obviously I didn’t need this in this case but it is an example of the good practice of ensuring that plugins and themes are not dependent on each other.)

For a better explanation of this see Template File Loaders in Plugins.

As suggested in the above post I made use of the Gamajo Template Loader which is:

A class to copy into your WordPress plugin, to allow loading template parts with fallback through the child theme > parent theme > plugin

I found this class really easy to implement and you can download it from GitHub.

Thanks to Gary Jones the developer who made it available.

Moving Jetpack’s sharing buttons

This is how to change the default display behaviour of the Jetpack plugin’s sharing buttons feature.

I’ve been using Jetpack to provide sharing buttons to Twitter, Facebook and the like on my personal site and was having an issue with where they were being positioned in a post. Because Jetpack adds the button code onto the end of the post content using a filter, they weren’t playing nicely with the elements in my theme that came after the post content. This was particularly noticeable when display the quote post format as the buttons were getting all wrapped up in a blockquote tag.

So I searched for a solution and eventually ended up with some code that strips out the buttons from the post content and then adds them back into the theme in the place where you want them displayed. Although I’ve not been using it, this code also does the same for Jetpack’s ‘like’ feature.

In your theme’s functions.php file add the following:

function jptweak_remove_share() {
if ( function_exists( 'sharing_display' ) ) remove_filter( 'the_content', 'sharing_display',19 );
if ( function_exists( 'sharing_display' ) ) remove_filter( 'the_excerpt', 'sharing_display',19 );
if ( class_exists( 'Jetpack_Likes' ) ) {
remove_filter( 'the_content', array( Jetpack_Likes::init(), 'post_likes' ), 30, 1 );
}
add_action( 'loop_start', 'jptweak_remove_share' );

Then where you want the sharing and like buttons to be displayed in your template files add this:

if ( function_exists( 'sharing_display' ) ) {
sharing_display( '', true );
}

if ( class_exists( 'Jetpack_Likes' ) ) {
$custom_likes = new Jetpack_Likes;
echo $custom_likes->post_likes( '' );
}

I actually wrapped the last bit of code in its own function and called that in the template for neatness sake.

The various if statements should ensure that everything works smoothly whether or not you have the particular Jetpack feature switched on or not.

The sources for this code are:

 

Coding Email Newsletters

I’ve been having a look at the current best practice for the design and coding standards of HTML email newsletters. I thought I’d turn my key findings into a brief check list to act as a prompt and link to some very useful resources.

The key thing to understand when designing email newsletters is that most email clients take a rather archaic approach to rendering modern web standards. This means that the best advice is to keep it simple and tend towards the lowest common denominator in coding standards.

Use tables for layout

Using DIV tags and CSS for layout in an email is unlikely to work consistently so the best approach is to “code like it’s 1999” and use tables for layout. So nest multiple tables inside each other and set padding and margins using empty table cells.

One tip is to set the width in each table cell and not to rely on setting the width in the table tag.

I like the suggestion of using one container table to set the width and background colour of the newsletter and then nesting within it separate tables for the header, body and footer.

Set a maximum width of 600px

Emails are usually shown in environments where the screen space is limited, often they are displayed in the preview pane of an email program, so the width of the newsletter should be limited. Most of the advice seems to be that 600px works best as a maximum size.

There is the issue of taking account the display in mobile being less than this, and the transfer of some responsive web design techniques into email newsletters to cope with this, but I reckon that if you keep the design simple mobile devices should cope reasonably well.

Even so a good tip is to ensure that your important content is placed on the left side of the email towards the top.

Use pixel units to define your sizes

Widths and font sizes should be defined in pixels. Support for percentages and other units is patchy.

Use inline CSS

Except for layout, as discussed above, do use CSS for styling but again it is best to aim for the lowest common denominator. It may be useful to check the support for the CSS properties your are using.

Always move your CSS inline. Once you’ve completed your design, you will need to go through and add inline styles to your elements – although some email services help you with this.

Also avoid using shorthand for fonts and hex notation. Hex colors such as #ccc should be written in full as #cccccc.

With paragraph alignment you should set the margin inline via CSS for every paragraph in your email. Do not use the float property in CSS instead use the align tag in the HTML.

Take care with the design of links

It seems that some email clients will overwrite your link colours with their defaults. To avoid this you should set a default colour for each link inline then also again set the colour using a redundant span tag inside the a tag.

Users will expect your links to open in a new tab or window so include the target="_blank" attribute in each link.

Be careful with images

Don’t assume that images will be viewed. In many of the major email clients, your images will not be shown by default.

So always include good alt text for every image. Specify height and width for images to ensure that the blank placeholders don’t throw your design off.

Also don’t rely on background images – use blocks of colour instead.

Finally, avoid using PNGs, they don’t get displayed in Lotus Notes, so stick to using use GIF and JPEG.

Alternatives

Include a plain text version of your email and/or a prominent text-based link to a Web version of your newsletter.

Use templates

I think my biggest conclusion from all this is to do yourself a favour and use a pre-existing template. If you are using a third party service to send your newsletters, such as MailChimp and the like, then they will have a range of existing templates for you to use and adapt.

Resources

Sources

Video: Luke Wroblewski – Mobile To The Future

This video is of an excellent presentation by Luke Wroblewski, author of ‘Mobile First’, from An Event Apart.

AEA Video: Luke Wroblewski (author, Mobile First) – Mobile To The Future

His key points are;

  • Mobile is the next form of mass media
  • We are currently in a process of transition from ‘the desktop web’ to ‘the mobile web’
  • So the process web designers and developers should engage in is;
    1. Taking what we know from the desktop web
    2. Adapting and optimising it for mobile
    3. Then finding new ways to do things that only mobile makes possible
  • He looks at how to do this through the examples of making a better login form and improving the online checkout process.
  • He concludes that the shift to mobile forces us to look again at what we are doing and find ways to do it better.

WordPress navigation and responsive web design

One of the trickiest things to deal with that I’ve been finding in committing to responsive web design is that it really challenges to think about your site navigation.

Generally speaking this is a good thing. Critical to the success of any website is clear and logical navigation — so anything that forces you to think more carefully about how your navigation works should be positive. Particularly if it leads to simplification.

So over the last few months I’ve been developing a little library of navigation patterns to use on the responsive WordPress themes that I develop. Essentially these patterns are about answering the question of what to do with your menu when the width of your screen shrinks down to the size used on mobile devices. Mostly these are using media queries with CSS, but some use a little bit of JavaScript.

In developing this library I’ve been relying pretty heavily on the ideas developed by Erick Arbe on his site ‘Adventures in Responsive Navigation’. This is a really useful resource. There are a lot of practical ideas here — but he also understands that RWD forces you to think about your navigation in different way. This WordPress.tv video also acts as a good introduction to these issues:

http://wordpress.tv/2013/04/17/erick-arbe-wordpress-navigation-in-responsive-design/

What I’ve not yet really tackled is what to do with the more complicated drop-down menus on responsive sites and the tricky issue of getting these to work with touch screen devices. Something that needs a more detailed post of its own.

Genericons: a free icon font

I was looking the other day for an icon to indicate a drop down navigation menu in a mobile layout. I wanted something that would be easy to implement, flexible, and relatively lightweight. I decided that I would do it using an icon font, but that meant finding a font to use.

I chose Genericons – and was so impressed with it that I decided to permanently integrate it into ‘Oystershell’ my WordPress starter theme so that it will be easily available for use in future projects.

Some example icons from the font.

It has been released by Automattic so it has a number of features that are really handy for WordPress users. This includes these icons designed to indicate each of the native WordPress post formats.

Changes to the typography on the Grit & Oyster website

Over the last few days I’ve been making some changes and improvements to this website. The most significant being a major change to the use of typography.

The Grit & Oyster website as it currently stands is a work in progress. I didn’t want to spend ages getting it ‘perfect’ and not getting it ‘out there’. So I had always intended to come back and make adjustments. However, I received some ‘friendly feedback’ that suggested I had got the typography wrong and probably needed to pay some attention to that aspect sooner rather than later. Which was fair comment.

My original choice of using EB Garamond with Junction had made the text seem too ‘busy’ and I hadn’t taken enough care with the layout and spacing of the text. The pages were not as comfortable to read as they should be, the overall effect was not the simple elegance I was aiming for, and there seemed to be some some problems with display on some device and browser combinations. So I decided I needed to make some changes.

I wanted to keep with using a Garamond as my signature serif font but I decided I needed to pair it with a simpler sans serif. I also decided that I would switch their roles. The sans serif would become the main heading font and the Garamond would be used for the body text.

In order to improve legibility in the body text I’ve moved to declaring just ‘Garamond’ for the body text in the CSS. I’m still using EB Garamond in various places for branding and ornamentation. The sans serif I’ve chosen is Droid Sans.

I’ve set the base font size for the content area at 18px. This has a line height, calculated using the golden mean, of 29px.

This means that all text, and other elements within the flow of a page, should fit within a grid of 29px.

This has resulted in a font scheme as follows (all measurements are in pixels):

[table]
,Font,Weight, Size,Line Height,Bottom Margin
P,Garamond,Regular,18,29,29
H6,Garamond,Bold,18,29,0
H5,EB Garamond Italic,Regular,18,29,0
H4,EB Garamond Small Caps,Regular,18,29,0
H3,Droid Sans,Bold,29,29,0
H2,Droid Sans,Regular,36.5,36.5,7.5
H1,Droid Sans,Regular,44,44,14
[/table]