TalentEd by ReadyDone

When To Build?

josh — Thu, 22 Jan 2009 01:25:50 -0800

One of the chief buzz words during the second wind of internet growth is/was "agile development." This phrase serves the web industry well, and can even have some relevance out-side the sector. It means, of course, adhering to a semi-regular schedule of iterative release... and more importantly a realization that perfection has little place on world wide web.

But even after we've all been whisked away to a magical head space where we're willing to concede our personal and professional shortcomings, learn as we go and listen to our customers... we still haven't agreed upon when to build.

All to often the decision to create is dictated by when the inkling is conceived.

In the best of cases, a set of previously dreamed up ideas are chosen from cyclically, based on an educated set of assumptions about users. This is currently about the best companies hope for. Register notions (internal or from outside), then prioritize based on effected user base and potential new users.

But what about that really awesome new feature you want to add that you're just sure will totally knock the socks off new and old users alike? You know, the one they don't really need. The one that Scott over at Funded.com Inc. just pushed live on his site. Should you build that into your system? Or should you speed up your page loads by 5ms?

I just had to bring it back to form vs. function didn't I. Useful alteration vs. bling. Should the web be an experience or an efficient source of information?

I bring up this question, because I think that each site/company/project needs to continually reevaluate which heading it falls under. The inevitable answer is both, but the questions remains: to what degree and in what portions of your online presence. When IMDB (internet movie database) serves a trailer, they are an experience; when they provide a listing of actors in a film, they are an efficient knowledge bank.

In which direction does your presence need to grow?

This may be just the right place for my anatomy of a feature release list...

Idea is conceived: you or your user(s).
Emailed, ticketed, feedbacked or mentioned orally.
Prioritized.
Building begins.
Pushed live.
User is wowed.

The key here is that we have to be ok with bumping something indefinitely. And sometimes dropping the bling project to listen to usefulness. Of course.

My current "when to build" belief is-- Hold out for desire. Act on need.

I'm tempted to say that only the big kids --Microsoft/Apple, Facebook/Myspace, Google/Wikipedia, Flickr/Youtube-- have the luxury of freedom to innovate bling. But we know that's not true. While they serve most of the eyeballs on the web, they too must follow the pull of optimization and house-cleaning against smooth experience and titillating innovation. Besides, innovation often comes from the edges and the new comers.

This doesn't mean you can't make time for un-affirmed improvement. You just need to hold off getting innovation "production ready" until it's at least actively desired. By the time it's an actual user need it should be in place and refined.

Choosing Your Website Features: A checklist from hell

josh — Wed, 12 Nov 2008 12:27:10 -0800

The industry term is "scope creep." The everyday human term is "a bunch of extra junk." Use this master list, and future predictions, to manage what you need and what will bring you value.

One of the first few questions you answer when starting a web project is what are the core features. What's our site going to do for people? The simple answer you start with usually grows into a rambling monster of: instant personal messaging, event auto-recommendations, mobile video chat, holograms and real life status pokes.

At this stage of the web game, there is in fact a suite of features that set the standard. It's hard sometimes to step back and evaluate the difference between industry baseline and creeping requests.
I thought it might be good to create a list of the top basic features; things that won't differentiate you. But the right combination, plus nailing even JUST ONE of them, just might.

This is a check list NOT to be crossed off. Your job is to choose the subset. It's the right combination of basic features, for the right people, plus of course your totally awesome new twist.

Present this list to clients and bosses carefully!

Search
Private Message
Blog Posts
Comments, Reviews
Profile, avatar, comment wall
Activity Feed (you and friends)
Photos and albums
Tagging content (contextual)
Similar Content
Easy signup, password retrieval
Groups
Voting, Up/Down
Filtering your view (popular, friends, recent)
Aggregating outside services
Categorized browsing
Private notes, contacts, data storage
Friends/Following
Contact Import
SMS/email posting
Members only area
Forum
Video posts and replies
Status updates / Micro posts
Forward and share
Bookmarking
Upload/storage
Collaboration
Wikis
Checklist/to-do
Events and Calendar
RSS (push)
Map representation of user or content
Customizable look/layout
Polls/survey
Notification, digest
Add to cart and checkout
Embedable elsewhere widget
Multiple languages
Desktop/Browser tie-in

*sigh* Now try and be choosy.

Course there are some newer features, that I'm sure will be standard by 2012, when Sarah Palin runs again. Ha!

(After reading over this again, I realized I should better explain some of these.)

Alternate discover/view mode
(fun and interactive overviews, timelines, etc)
Personalized recommendation, filtering
(inferences from your settings and habits)
Rich media meta indexing
(cracking the audio and video meta content barrier)
Organic data organization/clustering
(sorting by semantic and contextual machine learning)
Comparative aggregation tools
(comparing large amounts of outside content)
Mobile location check-in
(where are you? hopefully passive listening devices)
Location specific content
(what and who is and was created nearby)
Natural language interaction
(normal text searching, applications and coding)
Site independent conversations
(threading and interaction across sites)
Automatic outside social integration
(take your identity and friends with you)
Hovercars
(they're already late)
Teleportation
(duh.)

Barring the last two, I do actually have examples. These aren't empty predictions; I'm saying these things will be standard in a few years. Their fringe now, not miracles. Here's what I mean: Vimeo toys, Digg labs, Strands, YouTube in-video linking, Google: gaudi - sets - in quotes - trends, Flickr draw searching, Pandora, MemeTracker, PowerSet, ChaCha, etc.

Get going with Drupal themes

josh — Mon, 20 Oct 2008 10:56:54 -0700

Drupal is great for adding features via modules. Inside of a few days you can have a pretty sweet site prototyped. But without a good looking wrapper your candy will look stale. There are lots of great themes out there ready to drop in with just a few minutes work. Without a little sweat on your part the site will lack flavor, and give off the appearance of just another Drupal site.

I've been working on a new project that is anything but, and in the process I've been teaching Drupal to a friend... we just came to themes. As a good member of the Drupal community, I started the project in v6. There are some changes to themes, but when I hit the upgrade page to further browse the differences between 5 and 6, I realized most people probably really need a starter list. I wish I'd had one. Much of my knowledge is still in Drupal 5, but I've tried to include some of the changes in this tutorial.

Here is a list of a few things you should be aware of to get a solid start in themes.

(Of course Drupal has a great Theme Guide, for multiple versions.)

Folders
Template Files
Template Base File
Regions
Hooks

Folders...

First things first, themes rock because everything that causes the site to LOOK the way it does lives in the theme folder (you probably already knew this.) That folder is sites/all/themes/your-theme-name. (This theme folder allows for multisites.) The cool part is that folder can have a bunch of theme, which you can switch between. Set one for admin, another for random users or even let your users switch if that fits your desires.

In the theme folder is the /images folder that holds all the theme specific images you need for that look of your site. NOTE: Files that will exist regardless of the theme are stored separately. In version 5: /files and in version 6: sites/default/files.

Template Files...

There are a few files that power most of a theme's layout. All of the files in the theme folder that end in .tpl.php are template files that determine Drupal rendered output. These files contain the HTML that finalizes each page. The master layout template is page.tpl.php. This file determines how all pages will be displayed. This contains your page structure tags, often much of the header layout, and most importantly the output places for Regions. If you have a layout in mind and a sketch in hand, then open up the page.tpl.php file and the style.css and create the basic layout.

The secondary template files are things like node.tpl.php, comment.tpl.php and block.tpl.php which determine how each of those are respectively output on a given page. Keep in mind that nodes can output as a list, table, teaser or full... and templates can then get more complicated as you perfect various outputs. In fact, you can even define a different template for each node type by creating files like node-product.tpl.php or node-blog-entry.tpl.php.

Template Base File...

The template base file is like the brains of a theme. It defines various functions that will take place before rendering Drupal output. It helps create breadcrumbs, can customize how usernames or avatars are displayed, can inject style classes and ids into elements based on what page you're on, and in v5 it was/is the way to call out different Regions, among other things. The base file is template.php. One of the most common reasons for editing this file is that a module asks you to in readme.txt. (You are reading all the module readme files aren't you!) Needing to edit the template file means that a piece of the module needs help in rendering the output function of the theme you're using.

Regions...

I think this is one of the most under-used elements of Drupal. Regions allow you drop a section of content (a block) into a region on the page. In your page template you can define as many regions as you want, wherever you want and via style sheet customize the look however you want. This allows you to have total control of layout with just a few files AND those few files are all isolated in the theme folder! As of v6 regions are defined in the .info file. I believe this is an indicator that regions are now being seen as a more essential and useful elements of themes, and Drupal in general. The only bummer with custom regions is that when switching between themes much of your content can disappear because the new theme doesn't have the region for your content blocks to land. (The database entries for assigning blocks to regions in admin/build/blocks are theme specific.) If you are providing multiple themes for admins or users, make sure they both have the same regions.

Hooks...

As a beginning themer, you won't need to write hooks. But this is a great time to add them to your vocabulary. One of the core structures of Drupal is hooks. They allows modules, themes and more to latch on to a thread of code being executed. If the Drupal core is processing something, like getting a user avatar, then Drupal is calling a function that provides a hook. A module can then, for example, edit the size of the image. This can then still be hooked onto by a theme function that places a link around the image. Anything that happens in Drupal, all the way down to core functions like write a comment, show a profile, write the date, etc. can be hooked onto and altered by a theme function. These are called theme overrides and are done in the template.php file. This, again, given the theme LOTS of power to alter the output, remain in a separate folder and easily switchable.

Hope this gives you a better jump into Drupal themes.

Teaching Drupal CMS

josh — Wed, 01 Oct 2008 12:34:02 -0700

Yesterday I took on teaching my friend Matthew from A Bollen Design about Drupal. We're helping with a project that, while there will only be a few users, seemed like a good fit for the platform. Normally my rule is that if you'll have a small team adding content then you should defer to a smaller CMS like WordPress, but this project will have a few more features just beyond what I think is reasonable for only WP plug-ins. It's not a tech project so I hesitate to think about custom development options.

I can't help but use the opportunity to log how I go about explaining the Drupal platform. First of all I'll mention that I've started with the Drupal v6.4 release. The v6 core has matured well, and many key building block modules have been ported to the new version. I went ahead and did the installation process, set up clean-urls, named the site, created a developer role with pertinent permissions, renamed the 'story' content type to 'post', created a taxonomy (category for v5 users) and configured some basic admin settings.

Admittedly, I softened the blow of dealing with Drupal. If you're setting up the platform for the first time then refer to your install and read-me docs, then return here for steps to discovery.

So step one, the first 'assignment'

Create a content type
Create a new taxonomy, assign it to a content type.
Create a few pieces of content
Change the theme
Look at the module page
Set-up the primary links menu
Turn on and place a few blocks

Actually, I only stated step 1-5 explicitly. He did 6 and 7, so I added them to the list because he was right. I think this list give you a good idea about the structure and tools available in the Drupal system. The only pieces missing are the various admin functions of Drupal. There is LOTS of power in: error reporting, stat tracking, comment settings, url aliases, input formats, not to mention actions. Plus of course the power that comes with multiple user accounts. But I argue that to get started, you need to learn the structure-- take the user system for granted-- and bypass the plethora of admin settings.
I recommend before you install any modules learn: basic content types, creating content,
taxonomy, blocks, menus, user management, roles, permissions, core modules, and then move on to all the other admin stuff. Once you've bothered with things like tweaking your "post settings", changing the date and time, and choosing which content types display post information in your global theme configuration... then you can drop a new theme in and start installing modules.

I DON'T know about the project you have in mind as you read this, but might I recommend you go peak at: cck, views, imagefield, imagecache, (imageapi), pathauto, and token to start you on your Drupal journey. I said peak, not install. Be sure to read up and compare options before you roll forward. And one last piece of advice...

...Install modules one at a time. Test them out, set up the configuration, use them, and only then move on.

Search Engine Cheat Sheet

josh — Tue, 29 Jul 2008 13:10:08 -0700

We offer our talent a few tools to pool info about projects; this way we save time and work more cohesively. One of our first "Cheat Sheets" was about SEO (search engine optimization.) Since the purpose of our TalentEd blog is to present such knowledge, here are some of the greatest hits for SEO.

The main goal is to let the engine know when you should be displayed. It has to guess about your purpose. Provide goods hints.

KEYWORDS

If you don't know what meta tags are then stop right here, that's your one lesson. Put a meta tag for keywords and another for description. You can also have a script dynamically insert keywords more appropriate for that specific page. PS: trying to double up words makes you look bad to search engine brains and wastes the small number of words you get.
Make sure to use h1, h2, etc. tags. They are more semantic and help with search indexing. Engines only pick up one of each on the way through.
The title tag in the head of your HTML document is also a premier way to describing the content with a simple title and some perfect keywords. Bonus point: if your title and h1 tag match, then the engine knows it must be true.
Go find out which keywords to use. Examine competitors; be more awesome. Don't just guess.
Repetitive keywords looking spam-ish? Search engines are real smart.

TAGS

Use valid markup, otherwise the robots will get lost while viewing your site.
Similarly, broken links make search engines, and people, frustrated.
Use the alt attribute in your image tags so that blind people, and search engines, know what they would see.
This goes double for image links. Include the title in link tags that surrounds images.
Include the title tag for links in general... at least the important ones.

URLS

If you're going to be content poor (small number of pages) then let your URL describe your purpose to some degree. (Large networks have the luxury of content to do the describing, i.e. Flickr, Facebook, Bebo)
It's all about the prominence of descriptors, so get your URLs readable.
If somone could read the address and understand where it will take them
then you're golden, i.e.
www.readydone.com/blog/jul-08/search-engine-cheat-sheet
Often
tied to URLs is your site structure. Make this logical and get yourself
a site map. You can have a page do this or even better provide a link
to an XML site map for the robots to eat up.

LINKS

A main factor in your relevancy is how many links come into your site and where they head to. The internet is a mesh of hyperlinked documents. You want to be a hub. There are lots of ways to get sites to link back to you... I recommend having great content.

Having a whole lot of great content will make you even more vauble.

Lastly, there are lots of other people trying to present their relevance to the web out there. They can be a great resource for exchange and sharing. Two web presences mingled is more than the sum of it's parts.

That's all you get.

Rich Content and Third-Party Services

josh — Thu, 03 Jul 2008 13:57:12 -0700

Many of the websites we help create include an element of so-called "rich media," in this case audio or video. Most people with this type of content can envision how they want it presented to users but the back-end how-to options are still a little fuzzy. Let's clear up our choices for cost, work flow, and distribution. These factors overlap, and remind us that we can't have our cake and eat it too... unless of course you want to pay for two cakes.

Work Flow

One of the most important aspects of creating a solution is that you need to
feel comfortable using it on an ongoing basis. If it's professional content then before it gets to
users it has to come from you and your team. So, should your team upload the content directly to your site? This could mean you will have to shoulder the costs of creating an easy to use upload and administration system. Should you rely on a third party to host your content and use you site as a distribution platform? Will your team/users be likely to upload content to http://www.podcastalley.com or http://www.youtube.com and run the feeds or embeds through your site? Do you want all media to be centered on your domain

Costs

You can see how the issue of cost is directly tied to the work flow. It's definitely cheaper to run though a third party in terms of development costs, but also for ongoing hosting costs. Depending on user base, serving audio and video can climb into the thousands of dollars a month. Sometimes a great hosted solution can have a small monthly fee and take care of your needs until it's time to develop your own custom solution. Sould you host your files? There are middle-ground third-party options to white label rich media. You'll pay to appear as the host and platform, but you won't have to deal with the headaches. There are also code packages that let you serve your own content too. Do you need to build a user interface to view, sort, edit and delete your content? Are there services out there that offer exactly what you're looking for? The ultimate question: which part of the system has to be perfect? Focus on that, get help with the rest.

Distribution

It's easy to forget that nine times out of ten your site won't be the only method of distribution. If you want a larger foot print your goal should be to expand distribution as far as possible. That means you become a hub and a marketing control point, but not the end-all-be-all destination for your content. If you have a podcast, you should be on itunes or at least have an itunes compatible feed for your podcast. This will allow a larger portion of the market to tune in. Push your podcast though http://www.odea.com, post your videos to http://www.current.tv, not to mention allowing personal embeds to the vast array of blogs and profiles. If you're using third party solutions, you'll often be included in their directories automatically. So, there's a start. The term used for the internet --web-- reminds us of how to distribute content. It's not the old pipeline model of television. Ask yourself how will my users FIND this content beyond just my site? How can they VIEW my content beyond my site? What are the various platforms for my type of media: software, websites, feeds, devices, etc

It's nearly impossible to separate these factors in deciding how to implement your online media solution. Keep in mind where you're starting from. If you're leaping online with content for the first time, take the chance to play with your options before diving into totally custom systems.

If you are a CONTENT CREATOR then you should be USING TECHNOLOGY not DEVELOPING it. Leverage the platforms that are out there to your advantage, that's why they were created. If you are a PLATFORM then let's build you a SOLUTION THAT INTEGRATES with the rest of the web. We can give users the tools to distribute their content wider or with more editorial control.