About PM4Web


05 November, 2014

Information Architecture for the Rest of Us

For the sake of simplicity, let's just say Information Architecture means your navigation structure or the menu on your website. Now before all you IA experts out there grab your pitch-forks and prepare to storm the castle, please realize this article is directed at 'normal people', business owners who've had websites made and their developer contributed nothing towards helping them design a well thought-out navigation structure. This often happens because a web developer is a programmer, not an IA specialist (fair enough really, but still a problem).

The only thing I'll add by way of a simplistic explanation as to what IA is is this: it's also about how information is organised on your website, not just how you get to it.

The point of this article is to help people handle their own IA, and this is definitely possible. I personally don't believe basic IA is rocket surgery, anyone can understand it - there's no highfalutin technology concepts involved, or vague terms like 'on the cloud'. Most of it is just common sense, understanding your audience, and adapting your website to accommodate them ← that is the key point. Basic IA is about arranging your navigation and information in a way which best serves your audience.

Navigation design is about organizing information so: 1) people can find it (using their logic, not yours), and 2) successfully disseminating the information you want to get out there.

The 'disseminating information' part may sound peculiar, even contradictory considering I've just said it's about making information easy for users to find. Consider this though; you may be a charity organization and are required to make available certain information to satisfy government regulations. Or, there could be rules about using your website you need to tell people about. With this kind of information, most people (visitors) aren't interested in it, but it still needs to go up somewhere.

Now that the 'disseminating information' portion is out of the way, let's focus on how to 'do IA' on your website. The easiest way I believe is to approach the task by viewing your visitors in terms of customers. This still can be done even if people don't actually buy something from your website (i.e. I'm using the word 'customer' interchangeably with 'visitor').

Once you break down your visitors into different types of customers, you can start designing your menu structure and organizing your text to serve their needs. Some people will only have one 'customer type', whilst others will have four, five or more. The more 'customer types' you have, the trickier it gets to do IA (not impossible though, just more thought is required).

Let's take an online learning centre as an example. A website which offers online courses in areas such as English, mathematics, and so on. If we were to break down the major types of customers they have, we might come out with this: 1) students, 2) teachers.

Students are the ones using the website to access material such as study notes, quizzes, etc. Teachers are the ones that login and create the courses, answer questions from students, run webinars, and so on. Now this is a good starting point, but you may have noticed something. There is actually a sub-division to the concept of a 'student'. And this is very important. You can have a prospective student, someone who isn't a student yet, but would like to become one. This is subtly different to someone who is already a student. And the reason why this is important is because their needs are acutely different. On the one hand, a prospective student is probably going to be interested in what the enrollment fees are. Where-as an enrolled student is going to be interested in accessing online resources.

Identifying and understanding the different customers of your site is the key. Once you know this, you'll make reasoned decisions about what your menu structure should be like. This is why you sometimes see classifieds-style websites with very overt navigation elements like 'For Buyers' and 'For Sellers' ← they know these are users with very distinct needs.

Thinking about your information in terms of satisfying needs (or helping different types of people complete their particular tasks) is what will guide you when designing your menu structure, including what to name pages and where to put text.

Join RSS FeedSubscribe to RSS Feed.

29 October, 2014

If You Build It, They Will Come...

There's a belief out there that if you have a good idea for an online business, build the website and users will magically appear (what I call the "if you build it, they will come" mentality).

This worked for Kevin Costner in Field of Dreams, but for the rest of us that don't live in fantasy land, it doesn't turn out that way.

It's tricky to talk about this topic because it makes me sound like a kill-joy or naysayer. I don't like to stand in the way of anyone's dream, whatever it may be.

However, I often come across websites which obviously look unnurtured or abandoned (e.g. you do a search in major city for something and it comes up with '0 results'). The only thing missing is a Flash animation of a tumble-weed rolling across the screen.

For whatever reason, the site hasn't been successfully commercialized. My guess is usually that the business owner has spent all their money on technology, probably outsourced it overseas because it was too expensive to get done by a local digital agency. They most likely haven't budgeted for any significant form of promotion or marketing. This is like taking a raft to a river without a paddle, and thinking the current is going to get you across to the other side.

And this is what I mean by the "if you build it, they will come" mentality. Maybe this worked back in 1997 when there weren't many websites around to compete against, but now, big companies pour huge amounts of cash into promotion - competition is exceptionally fierce. Of course, in the absence of big dollars for TV spots, there's always viral marketing, but for most people this is easier said than done.

Another factor which hamstrings a website before it's even launched is the revenue model. Trying to charge people a subscription fee on an unproven platform is an uphill battle. What about banner advertising then? That's probably not going to work because the site doesn't have high enough traffic yet. A hall-mark of the current web epoch are websites that charge nothing (often they are looking for traction, then a buy-out later down the track). If established competitors are offering their services for free, then how on earth can a low traffic start-up hope to gain a foot-hold by launching and asking users to pay?

It's the dot com dream which lures people to the idea that web is easy money; this simply isn't the case. Sure, it costs far less to establish a website compared to opening a bricks and mortar shop. There's no factory equipment to buy, no materials used in production, cheaper insurance, etc. That's great, but you can have the most fantastic product in the world, but if no one knows about it, it's destined to fail.

I guess the point of this article is to not view a new website idea just in terms of the cost of the technology (i.e. paying programmers to build the thing). I often say to clients: "whatever budget you have for the website, have that again for marketing." The other advice I give people is this: "technology is the easy part, getting people to use the website is the hard part". Actually, the technology often isn't that easy when it comes down to it, but it's a relative measure - whatever headaches are experienced during the build phase, they are nothing compared to what's to come once the site is launched (i.e. attracting customers).

Does this mean it's all doom and gloom? Don't bother investing in a start-up idea, too hard, don't try? No, I don't believe that, I've partnered with business owners to developer online software knowing full-well the marketing budget was tight. Am I also guilty of the "if you build it, they will come" mentality? Perhaps, but the difference is I at least know before-hand visitors won't magically appear after launch.

Join RSS FeedSubscribe to RSS Feed.

01 September, 2014

Are You Missing Out on Maintenance Dollars?


A Quick Re-cap
















01 May, 2014

Customization and Change in Software Development





Enter WordPress, Our Savior...





Join RSS FeedSubscribe to RSS Feed.

20 April, 2014

Programming Style Guide for Classic ASP

The purpose of this article is to present a basic yet complete coding style guide which you can use with your development team.
General Rules
The reason why a programming team has a style guide is for the sake of conformity. In other words, even though the code is worked upon by 3-4 different people, it should all look like it’s been written by one person. Conformity leads to better maintainability in the long run (e.g. bug fixing becomes faster and adding new features gets easier).

There are 3 ‘golden rules’ which should be followed when coding on projects, they are:

1. Functions should be no more than one screen length in size
2. Don’t do anything clever
3. Don’t do anything stupid

Further explanation...

Functions should rarely be longer than one screen length in size. If you find you've written a function which is longer than one screen length in size, try break out a block of code into a separate smaller function if it makes sense to do so.

Also, if you see your function is performing two distinct tasks or operations, break it out into two smaller functions. For example; imagine you are calculating a user’s age, and then displaying their profile in the one function; that should be broken into two separate functions. This rule isn't always practical, you will occasionally get a long function if you have a large switch statement. You'll also get a long function if you have HTML/UI code to render. But at least 8 out of 10 times, functions can be written which are no more than a screen-full in size, this is definitely possible.

The reason why you should be writing small functions is utilising the OOP principle of modularisation. In the long run, this improves the maintainability of code and reduces bugs by breaking up tasks (functions) into smaller units. Imagine you have to come back to debug a block of code 3 months after writing it. Most likely your memory of the function would have begun to fade, it’s easier and quicker to get re-acquainted with a smaller block of code. Also, consider the very real possibility of someone coming back to debug your code, it’s going to be easier for them to understand a smaller block of code vs. a large slab of code.

“Don’t do anything clever” means don’t write unnecessarily complicated code. If you can write 3 lines of code which is easier to understand than 1 line of compact code and does the same thing, write 3 lines. Again, this comes back to maintainability. Someone else may need to debug your code later down the track, so do what you can to make it easier for. If it’s a very straight forward line of code, then it’s OK to put it on a single line - e.g.:

if (strFirstName = "") then Exit Function end if

“Don’t do anything stupid” isn’t about making mistakes, mistakes are mistakes - they happen, we’re all human. What we are talking about is doing things where you know better. For example: checking-in code before testing it, or not backing-up files before making major changes, or changing a password and not letting other people know about it, or having a problem with your work and keeping it to yourself, rather than telling your manager and asking for help.

This section relates to writing CSS code which is used by the software's front-end.

Class names should always be all lowercase:

Good: login_user_name
Bad: Login_User_Name

Separate each word with an underscore (not a space):

Good: login_user_name
Bad: loginusername

If you need to create a new CSS class, it must be placed in the \css\main.css file (or whatever file is considered the main CSS file for the software).

If you need to create a whole new CSS include file, it should be placed inside the \css\ folder. Creating an entirely new CSS include is rare, it would only happen if for example you were adding a large new sub-system to the project (e.g. forum.css).

CSS class names should be descriptive, but generally no longer than 3 words:

Good: menu_hover_over
Bad: m_hoverover

ASP Code
Even though vbScript is a loosely-typed language, it’s advisable to prefix variables with a data type. This occasionally helps with debugging as bugs occur due to data type mismatches.

Use the following data type prefixes:

i = for integer (e.g. iCounter)
str = for strings (e.g. strStudentName)
f = for floats (e.g. fDollarAmount)
obj = for objects (e.g. objRecordSet)
b = for bools (e.g. bRtnValue, bHasBeenDeleted)
...Arr = for arrays (e.g. strArrWeekdays, iArrProductIDs)

When using bool values, use the naming convention of bHas... or bIs... (e.g. bHasExpired or bIsVisible). This naming approach results in more readable code since you can write 'English-like' questions, for example:

if (bHasBeenDeleted = true) then...

Use camel notation for variable names:

Good: strFirstName
Bad: strfirstname
Bad: str_first_name

Generally, underscores aren’t used with variable names. The exception to this rule is global variable (which should be rare anyway), these should be prefixed with a g_...:

Good: g_strUserName
Bad: gstrUsername

Use descriptive variable names rather than short indistinct ones, but within reason. Try describing the variable within 3-4 words at most:

Good: iCounter
Good: iNumberOfStudentRecords
Bad: x
Bad: i
Bad: iTotalNumberOfStudentRecordsReturned ← unnecessarily long

It’s better to have a variable name like iNumberOfItemsToShow than iNoItems. Descriptive variable names make code more readable, which improves maintainability in the long run and reduces debugging time. Imagine you have to come back to debug your code 3-4 months in the future, the code won’t be fresh in your mind. Also, think about people who may have to debug your code, descriptive variables will help them.

When working with arrays, consider creating constants to use with them. This is especially helpful if the array is intended for use within more than one function. For example:



This makes it clear what data is being held in the array element. This in turn reduces the risk of bugs in the long run.

This section talks about how functions should be written within code.

At the beginning of most include files (.inc), there should be a start-up function (e.g. BlogStartUp()). This is generally used for initialising global variables used within the module/include file:

Function BlogStartUp()
  g_strArticleID = Response.QueryString("article_id"))
End Function

We use camel notation for function names, except the first letter of the function is always capitalised:

Good: LoginStartUp()
Bad: loginstartup()

Long function names are better than short undescriptive ones (within reason):

Good: GetNumberOfActiveStudents()
Bad: GetVal()
Bad: ProcessStudentRegistrationInformation() ← that’s far too long

You must use local variables as much as possible and pass values to functions, rather than rely on global values. It’s OK to use global variables occasionally, you just shouldn’t rely on them too much.

If you find you need to pass a large number of values into a function (e.g. 10+), consider passing an array of values instead. For example:

Good: Call SaveStudentData(strArrStudentDetails)
Bad: Call SaveStudentData(strStudentName, iAge, iEnrollmentStatus, iStreetAddress, strSuburb, strZip, iCampus, iGender, iCourseCode)

If you have a recordset object, you’re better off passing it to a function ByRef rather than sending a big list of parameters. For example:

Function DrawStudentSummaryList(ByRef objRecordSet)

When writing a new function, think about including some basic error checking if it makes sense. This is especially important when the function needs a passed value to work. For instance, imagine a SQL query like this within a function:

strSqlQuery = "SELECT * FROM tbl_users WHERE (status = " & iStatus & ")

What would happen if the iStatus parameter was empty? You'd get a script error. To avoid the danger of a crash, you should add a line of code at the top of the function which looks like this:

if (iStatus = "") then Exit Function end if

When a function is created specifically to return a value, prefix it with the word Get...(), for example:

Function GetAccountStatus()
Function GetNumberOfTickets()
Function GetUserFullNameByID()

Functions which perform some form of processing and then return a value should have a specific variable which has the data type plus the word ...RtnValue. For example:


When a function is written to save a value of some kind, it should generally be prefixed with the word Set...(), for example:

Function SetActiveMenuItem()
Function SetUserLastLoginTime()

If a function contains HTML code and is rendering front-end UI of some kind, it needs to be prefixed with either Render...() or Draw...(), and post-fixed it with the word ...HTML(). For example:


Query Strings
When creating query string variables to be passed via hyperlinks, they should be named all lowercase with underscores in place of spaces. If an ID is being passed, then the query string name should end with ..._id (e.g. blog.asp?blog_id=45). Query string variables should be descriptive, but generally no longer than 3-4 words in length:

Good example: <a href="blog.asp?blog_id=1">Buying a Cat</a>
Bad example: <a href="blog.asp?ID=1">Camping</a>

Form Controls
Form fields should be named in a manner which gives an indication of their control type, for example:

<input type="text" name="txt_age" value="" maxlength="8" />
<input type="checkbox" name="chk_agree_to_terms" value="1" />
<input type="radio" name="rdo_gender" value="1" />Male
<textarea name="txt_about_me"></textarea>
<select name="drp_day"><option value="1">1</option></select>

This naming convention can be useful when it comes to server-side logic. Knowing the control type helps with debugging or processing data before inserting it into the database.


1) textbox controls should always have their maxlength attribute set 2) textarea controls use the same prefix as textbox controls (it’s just text after all).

If you need to use an ID with a control due to JavaScript interactivity, the naming convention for IDs has the control type at the end rather than as a prefix. For example:

<input type="text" name="txt_age" value="" id="age_textbox" />

<input type="checkbox" name="chk_tax" value="1" id="tax_checkbox" />

<input type="radio" name="rdo_join" value="1" id="join_radio" />Yes

<textarea name="txt_about_me" id="about_me_textarea"></textarea>

<select name="drp_day" id="day_droplist"><option value="1">...

Note: the ID attribute is named differently to the form control name to avoid confusion between the two.

File Names
This section relates to the naming conventions used for all files found within the website’s folders.

File names should always be all lower case and use underscores instead of spaces:

Good: database_connection.asp
Bad: Database Connection.asp

Longer descriptive file names are preferable to short ones which give no indication of what the file is (within reason). Usually a maximum of 3-4 words will do:

Good: duplicate_username_check.asp
Bad: dup_check.asp
Bad: perform_duplicate_username_check_operation.asp ← too long

These same rules apply for all other file types like JPEGs and PNGs (note: GIFs are rarely used these days, they’ve mostly been replaced by PNGs).

The reason for descriptive file names is it helps when trying to identify what a particular file does amongst a larger list of files without having to open up the file.

This section covers conventions to be used when working with database tables and fields.

The rules for naming database tables are as follows:

• use only lowercase characters
• use underscores in place of spaces
• table names are prefixed with the letters tbl_
• table names should rarely be more than 3-4 words in length
• tables should nearly always end in ‘s’ (indicating plural)

For example:

Good: tbl_students
Good: tbl_countries
Bad: Error Code ← should be: tbl_error_codes
Bad: UniversityStudentRecordDetails ← too long

Datababase fields should follow these rules:

• use only lowercase characters
• use underscores in place of spaces
• primary and foreign keys must start with id_
• rarely be more than 3-4 words in length

For example:

Good: id_student
Good: first_name
Bad: enrolmentStatus ← should be: enrolment_status
Bad: recordID ← should be: id_record

Note: one of the reasons why primary keys always start with id_ relates to protecting against SQL-injection hacks. You can have a wrapper function like QStr() and RForm() which strip the characters id_ from strings.

When creating fields used to store a bool condition (e.g. yes/no, active/inactive, show photo/don’t show photo, etc) - use a tinyint data type rather than a bit. 1 is used to indicate true and 0 represents false. Using an int provides flexibility in case more conditions are added in future (e.g. 1 = active, 0 = inactive, 2 = suspended).

Join RSS FeedSubscribe to RSS Feed.