Generation Loss from hadto on Vimeo.

What is a Weblog?
This is the first place I got stuck. I assume you already have a conceptual understanding of what a weblog is, so I’m going to speak specifically within the context of EE. In a single installation of EE you can create many “weblogs”. The thing is that what they call a “weblog” should really just be considered a container for content that behaves like a conventional weblog. These “weblogs” can be renamed to something more semantically meaningful to your project. For instance, instead of using the term “weblog” you can change it to be “site” or “monkey”, or whatever – you decide. The important thing to remember is that no matter what you call these “containers” – weblogs, sites, or monkeys – they can have their own set of administrative rules that are configured separately from the other “containers”. A “weblog” titled Energy can have its own set of Categories, its own Template Groups, its own set of Member Groups, and its own Members. In this way EE is very flexible.

This flexibility was one of the reasons we chose EE for our project. We needed a platform that would enable the creation of separate “sites” for a number of different user communities that could then be aggregated into a single portal view on the home page, with a shared administrative system to control editing privileges, template features, and security for those different communities.

What Do You Mean “Groups”?
This was the next fuzzy experience I had with EE – Groups. There are five administrative areas in EE that are referred to as groups:

1. Category Groups – these control the categories that are available in a particular “weblog”. Configure these by going to Admin – “Weblog” Administration – Category Management in the Control Panel
2. Field Groups – these control what form fields are available on the New Entry page when posting to the web site. Configure these by going to Admin – Site Administration – Custom Site Fields in the Control Panel
3. Status Groups – these determine the workflow of new posts within a “weblog”. The default statuses are Open and Closed, but you could add more such as Draft or Live if your site requires more control in throughout the editorial process. Configure these by going to Admin – Site Administration – Custom Entry Statuses in the Control Panel. These are directly tied to Member Groups in that you Assign Member Groups to Status Groups (to control how how members of each group are able to post content to the site)
4. Member Groups – these control who has what permissions on the web site and within different “weblogs”. Configure these by going to Admin – Members and Groups – Member Groups in the Control Panel. New Members are then assigned a Member Group when their accounts are created.
5. Template Groups – these drive the appearance of pages depending on which “weblog” is being viewed. This makes it possible to have separate areas of the site that look totally different or that share components among each other. Configure these by going to the Templates tab in the Control Panel. Assign a Template Group to each “weblog” configured on the web site.

Each of these types of groups can be configured differently for each “weblog” (or “site” or “monkey” – whatever you call your containers) in your EE installation. Each time you create a new “weblog” in your EE installation you will have to specify which groups are to be used for that new area of the site. Keep in mind the you may not need more than one “weblog” in your EE site, in which case you would only have to set up your groups once.

Where Am I? (Link Structure)
This was the hardest characteristic of EE to wrap my head around. In fact, I still don’t feel comfortable with it. EE builds templates dynamically from the database. Template Groups names and Template names determine the URL of pages. For example, the default address of the home page of an EE site is:

http://websitename.com/index.php

All other pages are built off of the index page because the templates are pulled from the database (by default). The address of a page displaying a single article would have an address built like this:

http://websitename.com/index.php/templategroupname/singlearticletemplatename/articletitle

The URL structure is very difficult to relate to at first. Fortunately, there are ways to get around it and make URLs look normal. Understanding how EE builds URLs, regardless of what the end users see, will help you as the developer leverage the flexibility of the templating system.

After I understood EE “weblogs”, groups and URL structure I was ready to actually tackle my project. If you haven’t looked at EE yet, the above information will seem mostly useless, I think. My next post will be on how to install the EE core (which is free for personal use). That way, if you haven’t seen it in action yet, you will be able to get your feet wet.

With this new approach to web development in mind, I encountered Typeface.js, a simple script that enables non-standard fonts to be embedded into web pages (see examples here). I say simple because it is way less involved that SiFR, which has become a popular way to “fancy up” text while still allowing it to be read by alternative devices, seen by search engines, and selectable by the user (for copy/paste/portability). The main drawback to SiFR in my mind is that is requires access to a copy of Flash and I am truly that lazy AND cheap.

Looking into it further Typeface.js seemed to be a less involved process so I gave it a try and had it up and running in a matter of minutes. Good stuff. Here’s the low down from my point of view right now:

Pros:

• Doesn’t require a copy of Flash
• Supported browsers include Firefox 1.5+, Safari 2+, and Internet Explorer 6+, and degrades gracefully in unsupported browsers
• Text can be searched, copied, and repurposed
• Draws *pretty* letters with clean, smooth lines for much better looking type, FINALLY
• The code is open and free
• A handy TTF converter is available for download or at the site, that converts True Type Font files for use on the web

Cons:

• It doesn’t support all CSS2 features, but it covers the basics and that’s all I really want anyway
• You must have copyright permission to distribute the fonts you want to use
• Doesn’t taste like chocolate

Wait, what was that about having permission to use the font you want to embed on your site? This is a very important thing to note, because typographers work hard too – hunched over their sketch books and laptops in the dark – making the cool fonts you want to use, and they have to eat. Not to worry, though, there are open fonts available for you to use if you’re in a bind. I like to think the typographers who have made these open available have rich benefactors or sugar daddies (or mamas), or are employed by large companies that give them regular paychecks and allow them to have some free time toward altruistic creativity. Truthfully, I just want to imagine them being well fed so I can use these fonts guilt free.

The MgOpen Collection (Get them here)

• MgOpenCanonica
• MgOpenCosmetica
• MgOpenModata
• MgOpenModerna

Just as a little note, Typeface.js renders text with cleaner lines than the image below displays

A while back we had decided to build the site using Expression Engine, a first for me. It seems lately I’ve been building a whole lot of Wordpress sites. Expression Engine is about as easy to work with as Wordpress, but for different reasons – all stemming from the fact that when push comes to shove WP is a blogging platform and EE is a content management system, so it isn’t a straight apples-to-apples camparison between the two. I will say that, in general terms, developing a site in WP or EE takes about the same amount of effort once you’re reasonably familiar with the systems.

I’m planning on writing a few posts around my initial experience with EE while all the questions and fuzzies are still fresh in my head, in the hope that it will straighten a few things out for me, and possibly help someone else out. I will add just one more thing about helping – the EE documentation was consistently the most helpful resource for answering questions.

More on EE to come as I try to collect this last project into something coherent.

Opera, one of the web browsers that has regularly enjoyed a notable amount of marketshare since the 90s (dare I say, since before the turn of the century), has since made a commitment to address accessibility and web standards issues throughout recent years. One of their latest projects is the Opera Web Standards Curriculum. Conceived to be a resource for instructors, students, and working professionals, the project attempts to make available a curriculum that includes a survey of the history of the internet, and an introduction to current, standards-compliant practices in web development.

The project is still underway, but the materials that have been completed are already available on the project site. In the end, they say there will be over 50 articles – all available under the Creative Commons Attribution, Non Commercial – Share Alike 2.5 license. I’ve reviewed the content and it is sound. It also attempts to give users access to a community they hope will form around the curriculum by way of a forum. As of right now, activity in the forum has been sparse, but to be fair, it IS new.

Most important, this effort attempts to address common inconsistencies in web development curricula across institutions where course material can sometimes lag a few generations behind due to the rapidly changing nature of the internet. I won’t go into the details of why this happens. There is enough material there for a whole other article.