In my last post, we were looking at a large picture perspective of web applications. I first must apologize for a misuse of terminology. I used the terms “PM” and “Project Manager” when referring to the role being described in my last post. Strictly speaking that would be incorrect as just setting up premade software would not concern a PM in all likelihood. I should have just used the term “manager”.

As we continue, we are going to look at usability and maintainability. We are going to continue to approach these problems from the perspective of effort/time and decisions rather than technical aspects except where very useful.

2. Usability

Usability is arguably the most important part of the project for a manager. This is really what needs to be reasonably well defined before hand and what can make or break the final project.

The largest and most important part of this is a well defined list of features. After all, this product is providing the users with access to some features. If they are good enough, the users will continue to use the product. If the features are lacking, convoluted, difficult or time consuming, wrong, inappropriate for the target audience or anything else negative, this can spoil the project. Since even though all these descriptors are similar they are still extremely important, I want to look more specifically about what each can entail. More importantly, how features could be better defined to remove the problem and give a better product.

Lacking features references when a product lacks an element of completeness to the user. This comes from a couple of ways. The most direct is when a product helps the user toward a goal but fails to help from the start or until completion. Having to use external tools or do more work by hand is generally unacceptable unless there is good reason why the product cannot do more (licensing, technical limitations, etc.). Even if it might be more work to do it by hand, users may choose to do all the work without the product then simply because it involves less context switching.

The more subtle way that a set of features can be lacking is when all of the features from start to finish do exist, but they are not well done. Not well done can refer to both flawed in a different way (possibly one of the ways described below) or that the feature itself does not provide enough help to the user to really be seen as a full feature. For example, if something expects html formatted input but only provides a text area, this is not very useful or friendly to the user (unless the user is known to be very comfortable with writing html by hand and not much writing would be needed).

How do we avoid this though? Well, use-cases can help to actually identify all of the features that really need to be developed. These use-cases need to be detailed enough to also convey technical knowledge of the user and then tested with that level in mind. Features that are not well done tend to only be discovered by tested (and frequently more public of testing due to people associated with the project might know too much to be able to evaluate short comings).

Convoluted features can pose another large problem. The actual cause of a feature being convoluted is two-fold. The first comes from the feature being hard to find. If it is not presented to the user anywhere, how can one expect a user to take advantage of it? I could easily see this coming up when you have say a bookmarklet that you want people to use. If there is no real way to find a link to this without prior knowledge, the feature is convoluted to find and essentially does not exist to most of the user base. Presenting a feature only where it is not relevant has the same result. These can be evaluated by tracing paths to how to find each feature and determining if that is a logical set of steps for a common user or not.

Being convoluted can also refer to a poorly explained feature. Sometimes this is the result of a bug in rendering. If you cannot see the explanation of a field, it is much more difficult to use. If there are constraints on input, these also need to be explained to the user ahead of the user trying to use the feature. Also, error messages should be useful when seen rather than cryptic or exclusively for debugging purposes. Error messages should also exist for all errors so that the user is well aware when something has gone wrong (and whether it was a random fluke such as a race condition, server error, or user error).

Possibly one of the most difficult things to test when the system is understood is how difficult or time consuming the features are to use. That said, it is also extremely important. After all, the service being provided is here to help users. In order to do that, these features have to be intuitive to use and helpful whenever possible. The best way that this can be thought out is by considering the actual use case down to each input. If a user has to enter 40 different values before they get any feedback, there is a decent chance something will go wrong. Also, when actually testing the product, the tests should be timed especially between interactions with the system (or some feedback at the very least like notifications of auto-saving).

Difficulty is something usually hard to measure by people involved on a project due to their understanding of what is required. This poses two possible ways to evaluate the situation: the most authentic way to test this would be to have the system tested by outsiders before it goes live. Finding good and willing outside testers is difficult and also is harder to get fast and good feedback. Because of that limitation, some evaluation still can come internally. The biggest question is how much effort must the user put in outside of the actual function to cause it to work. Does the user need to already have certain figures calculated? Can the product be expanded to help with that? Can any prerequisites be helped by expanding the product some? Conversely, is the product forcing the user to accept its help when a user may be able to figure out the answer on his or her own without the need of assistance? Answers to these questions are important and should affect how the product exists when it is moved into production.

Possibly the easiest one to test is the validity of any output generated by the product. This is somewhat of a demand to really unit test and hand test each and every feature. If there are limitations, can they be either handled gracefully or is the user informed? This I won’t go into so much because this actually would come up mainly in development and can be handled to a large degree there.

Our final question that management should investigate is whether or not the features are appropriate for the target audience. Exactly who might be included in the target audience is very important. If there are several categories, each feature needs to be evaluated from the perspective of that category. Appropriateness is evaluated through many of the above methods. Is there appropriate information to allow the audience to use the feature in a timely manner without problems? More importantly, would this audience actually use the feature? Can you make the feature more useful? It’s possible that the fact that an audience would not use a feature is acceptable (like advanced users may not take advantage of a guided mode). This should explicitly be realized and probably documented. Also, if there are distinct groups of users, maybe the product should tailor itself to present the most appropriate features first.

4. Maintainability

When thinking about a product, how much work it will need in a years time or maybe several years. A common thought is that the set up is likely to be replaces. Experience will dictate otherwise in many situations though. Maintainability needs to be considered in a number of situations: work needed to update, expand, move between hardware, and tightness to dependancies. Again we’ll look at each individually.

Even after a product is done, it is very likely to need updates. No where is this more important than the web where the exposure to the world is huge. As such, the ability to roll out a new update successfully is key. Success in an ideal world means next to no work from the administrator and no noticed downtime from the users. The more complicated the system, the less likely this is. If the product is packaged, it is good to look at how updates are distributed ahead of time so that an idea of effort can be gaged. This gets more complicated also in distributed systems. Can an update be applied one server at a time and they all continue to cooperate in the mean time or does it need to be instantaneous? What happens to any users currently logged into the system? A large concern is data loss. If someone is working in the system as something is updated, will that work be lost? The web is in reality stateless though state is frequently hacked on top of it. Any changes to how state or caches are handled can cause problems for users. Can users be warned about an update that is coming up?

With answers to these questions, one still needs to look at what has to be done on the administrator’s side. Can the update be completed completely from the management interface? Is direct database access required? From a manager’s point of view, how many people will be needed to normally maintain as well as update the system? Needing a full team of IT people to stay late to do an update is costly to the company. Choosing a product that someone without technical ability can update with little effort is much cheaper in the long run.

Projects frequently start much smaller than they end up if they get popular. As such, a question of how to expand this project is very important. This can be important for clustering and redundancy. Does the product itself actually handle being distributed or is that something that has to be handled at the server or database level? Very database oriented applications frequently can be simply handled by using clustering and redundancy features built into the database. If, however, the program also uses local temp files, suddenly load balancing is much trickier. Also, does the product handle increases in hardware gracefully or not notice? If something has to be reconfigured to actually become aware of changes in say RAM, this is another sticking point in long term maintainability.

Hardware changes begs another question of just moving servers. Frequently it is useful to move software to different hardware for better reliability or performance, but some software is not as easy as others to move. Could one server be brought up and another taken down without any noticeable change to the outside world? Can any problems be reduced or removed by simply running the system in say a Xen or Hyper-V virtual machine? If that would work, can the organization support this?

A lot of the questions of moving between servers or hardware might actually be more related to the software’s reliance on the underlying system. It might be very beneficial to performance to take advantage of certain aspects of the operating system. This could create a dependancy on that operating system. Though there currently is a good administrator of AIX systems, is it a wise idea to require the software to run strictly on those systems? More commonly, there can be dependancies on libraries and the like. Most of the time the binding is loose enough that the library can be upgraded past the starting point without any problems. This is not always true. If, for instance, the program was built against a beta version of a library, the actual interface might change in the future. Because of this, an update may actually break the system. This can also exist in underlying languages. If the solution is java based, for instance, would it work well with different java runtime environments? I have personally seen software that would not work correctly with java versions later than a certain point. Sometimes this can happen with interpreted languages too. How much does the software depend on deprecated code? Is it documented so that future administrators can determine whether or not it can be upgraded?

I realize this has been a long post, but I hope it helps with planning projects. After all, better products come from better planning. As a developer though, I believe that it would be good to actually look at approaching how to implement some of this and the ease of development. In my next post we will start to look at advantages and disadvantages of various web languages and frameworks. If you have any comments on what I presented here or would like to contribute to that post, please feel free to email me or post a comment below.

I am by no means an expert on many topics including the ones I want to look at. I do argue that to be a feature in the regard that most of the world is not experts. Because of that, I can present a user’s perspective to a lot of topics.

I have wanted to see a wonderful and accessible web for a long time. From the client side, we have achieved that to a great degree. Browsers are actually overall acceptable products. I will not call them perfect by any means, but I do not think that a large concern of the web needs to be focused on the client. Instead I want to focus on the server side.

There are three major aspects to any application that are not foreign to the web: setup/development, usability, and maintainability. Now I usually play the role of developer on projects, but I am by no means foreign to the Project Manager role or big picture. For this post, we are going to stay with the big picture. To be very clear, we are going to start by defining each of the terms rather specifically:

Setup/development

Though these seem like two steps, they reference the same goal: what it takes to get the software running on the server. Setup here is referring to deploying premade software. These can differ greatly with a “from scratch” environment and something that exists. Development on the other hand references both man-hours needed to get the software created as well as the time based around the learning curve. This can differ for people of different backgrounds and should be approached from different perspectives.

Usability

From the web application’s stand point, there are two ways this must be usable: can the administrator easily achieve whatever task he wants (such as generating content) and can the users easily access and consume the results (such as reading the content). We are strictly looking at the amount of work needed for the day to day use of the product

Maintainability

Even when shipped, software is never really done. The web knows this to a great extent with regards to security. This also comes up with support from underlying technologies. For instance, does the software no longer work with future versions of the language interpreter/compiler? If so, now old software must be kept or new software needs to be located. This looks at from a required interactivity level, what needs to happen to keep the software in a safe and usable state.

I unfortunately have not tried everything I want to talk about. If at any time I misspeak or you have a different opinion, please bring it up. I would like more of a complete discussion than just my views. That said, I am going to generally only look at ASP.NET, PHP, Ruby, and Python and some applications and frameworks on those when talking. There are many more technologies that exist and I am happy to look into more if there is a compelling reason. For this post, however, we are going to stay above a lot of technological specifics and just look from a manager’s perspective.

0. Hosted solutions

The following discussion does not really apply to solutions hosted by others. This is because setup and maintenance is removed. Usability is important and out of box value is crucial. For hosted solutions, only configuring during start up and usability apply. It is assumed that the hosting provider will take care of the rest (which is a feature when what is provided is good enough, but tends to add cost as well as limits use besides sometimes causing legal problems for organizations).

1. To begin

All products need to get onto the server somehow before anything can really happen. This seems like a good place to start.

a) Set up

A very common situation is where some product is desired that already exists (mostly or completely). Even sometimes glorious ideas are really just different ways of expressing known problems. Some of the most common desires on the web are blogging, wikis, content management, and project/bug management. These flavors of problems can actually exist in many ways. For instance, a blog is very applicable if a small company has generally one source of news and some static pages or some site posting news. Wikis work well when trying to have collaborative document generation or simply a system for developing documents. Content management systems work for more general case web sites that tend to want to fill multiple roles at one time such as file/media management, forums, articles, and possibly more. The last category is generally set up for those working on projects (this includes non-technical ones) and/or developing software. There is many more categories of software available, but from the set up perspective, they all act about the same.

Finding appropriate software for a specific goal frequently is not trivial. This comes from the abundance of software that exists as well as constraints for the software itself (such as needed features, language/system requirements, etc.). The worst part is seeking a decent amount of features that are available with work from multiple sources. Generally, the concept that time is money is the best thing that I can suggest. When trying to start looking for software, try to limit the field as much as possible first. Less choices for whatever reason will allow you to either pick a product or choose to develop your own much faster than trying several.

Assuming software has been selected, installation actually occur starting with prerequisites. Package managers and installers really make this part easy is most cases. Installing databases, apache modules, and various other components frequently can be taken care of by either some other system or is described in the installation documents making this step the most predictable in general.

The final step of set up of premade software is configuration. This is frequently where many problems will occur and time will be lost. A concept briefly mentioned in point 0 is out of box value which is very important here. Products have a certain number of features contained in the default install. These features and the quality they provide can be described as the out of box value as no additional software was needed to achieve it. For many large projects though, there exist add-ons and plugins that will provide even more features. Sometimes that is the only way to actually get a desired feature. These frequently become a consideration for long term use though. This stems from compatibility between plugins and the main software versions as well as any required changed needed to make the plugins work. Many can simply be moved to the server and enabled through an administrative interface. Others may actually involve hacking part of the code of the product. The latter is much more prone to error and problems though the former is not without them either. Speaking from experience, something like WordPress (which runs this blog) allows plugins to attach to methods. These methods may be called all the time and could render the entire product unavailable until it is reinstalled or the database is manually edited to revert changes (which is how I fixed one problem with plugins). To truly get a system working the way that is desired, a lot of time is likely to be invested in configuration.

b. Development

Again, we are approaching this from a PM’s perspective for now. Actually creating software from scratch is time consuming and costly in a lot of regards. That said, you get full control over what is created and can therefore get the maximum out of a system. You also can basically remove configuration as everything will be built to fit the situation.

The entire cycle has to start out in the planning stage. The actual objective needs to be defined along with constraints. Due to a lot of organization’s limitations, outside code might be somewhat limited (based on licenses amongst other potential problems). The amount of available outside help (speaking of code, not contractors) as well as time constraints can change a project from following the best or latest means to being something more within the developer’s skills. If at all possible though, the best tools for the job should always be chosen. We will look at this from the developer perspective in the next post where we actually try to find the best tools for the job.

Effective development will need to have the actual code-writing section overlapped with a testing section. If large enough, people could be tasked with strictly testing the code and setting up automated tests for more thorough coverage. The web is an interesting beast in that 100% code coverage is almost required by tests because the potential user base can easily find all the errors that were missed in development. Also, a bug released to the internet could give arbitrary outsiders access to central points of data that are very critical. As such, a good testing phase is very necessary. Also, documentation should be written for all of the code. For this code to live on past it’s current developer, how it was made absolutely must exist (and be written in more of a “what this does abstractly” rather than a “what this code exactly does” sort of way; this will also keep documentation valid for longer even when the code changes).

I am extremely well aware that how to do all of the above is very abstract, but I think it is all better addressed from a developer’s perspective. From the manager’s stand point, development may give you a better product for your needs, but it is very costly to do right.

[Due to the fact that this post is probably over 1700 words, the rest of this is posted in part 2 of this series. The developers perspective on actual development comes after that and soon!]

I’ve taken to running svn releases of WordPress. I don’t exactly have a good reason, but it does seem to make themes not work right. (I tried to use two different themes because i’ve been doing a lot with dark backgrounds and light text recently. it went poorly). On the bright side, the new interfaces seem slick and the updates are easier using straight svn access.

For development, I’ve come to find that I’m either in vim or Visual Studio 2008. That’s pretty much the two ends of the spectrum of light and generic program to highly customized and heavy for development. I’ve been doing some development with C#.net and really have to say it’s fun. I love programming in it probably more than any other language. I’m enjoying the environment too. I admit, I kind of miss my vim key bindings and jumping into normal mode to move around, but it’s not all bad. The code completion and intellisense is great in VS2008. The debugger for applications in extremely nice to step through whatever has gone wrong. I really must say that I miss those capabilities when I’m writing something else.

Also, since I mentioned running light text on a dark background, I would suggest altering your theme (if your window manager supports that) to light-on-dark. It’s very nice on my eyes and you can find great places where only backgrounds or foregrounds were specified, making them unreadable! Well, at least it encourages you to think about what happens when someone does try to use high contrast light-on-dark settings with your program/web site. Accessibility forever.

I’m going to be honest. I enjoy writing web apps. I really enjoy the back end code and the product at the end. I have done pretty much everything of significance in PHP also. This shouldn’t offend anyone yet, but some people might see PHP and think less of me. And the real question becomes why?

Now I’ve asked a lot of my friends this question. The general answer usually comes down to PHP yielding bad code or being unmaintainable. Um… I don’t think that’s PHP’s fault that the last person who worked on this project kinda hacked it together into somewhat working but terrible shape. Most if not all programming languages allow you to write bad or unmaintainable code (purely functional languages might be the exception, but my experience with them is far too limited to be able to comment). To be quite honest, I don’t have a problem maintaining my php code. Larger projects always have a framework (one I made usually) to power them and small scripts can easily be navigated by using find in the file or scrolling.

Well Rails and Django are amazing frameworks. This may or may not be true. Rails does have a lot of cool features. It is even cooler when you start giving it extra gems. I’ll give it that, but even that isn’t good enough for me. If you actually want to start using more complicated conditions, you end up writing the SQL you were looking to avoid. Something like Symfony provides most if not all of the commonly requested features for php. There are many other frameworks available too. So if one isn’t good enough, you can always try another.

PHP is slow. To be honest, PHP is usually not where scripts end up being slow. I frequently see one of the following: 1) Are you having PHP do calculations that your database could easily do? Why would you do that? 2) Are you having PHP parse pages that are static or virtually static? Why not use server side includes and not even use the php parse? 3) Did you make a huge data structure that you are recreating on every call? Look into functional programming or restful programming (both are stateless) and consider revising your code.

And in the end, PHP has a lot of well known ways to speed it up. Why not try out a caching solution? memcache is nice and well supported. You could even implement your own.

Are there any reasons to use PHP, not just defend it? YES! Plenty. Integrating kerberos authentication is extremely easy. There is a wealth of information about any common task. the PEAR/PECL code is common and usually easy to use. The wealth of code already available makes it a simple choice.

I noticed that there aren’t many (if any) good cURL tutorials that show you some of the power of cURL like manipulating cookies and such. Such a tutorial could be used for good (such as unit testing your work) or evil (trying to program a bot to do something that requires a login). After I get my contrived examples created and can demonstrate them, I’ll write up the tutorial that looks at cURL in more detail. This is supposed to both show users how to use cURL better as well as for site administrators to get an idea what could cause vulnerabilities. I will also discuss ways to create login systems to defeat cURL.

To be posted soon…

So what is most of the web like according to Nomensa (referenced in the BBC article)? Almost all major sites do not even provide basic access to those needing assistance such as screen readers or magnifying tools. That is not acceptable. We as web developers need to think about more than just how pretty things are. Standards are your friends! Follow them and all of these problems will virtually go away. The article is a good read. Even if you do follow standards. The article is ‘Most Websites’ failing disabled.

Oh and if I remember, I have some music news to post as well.

Let’s look at IE 7 first. If you’re like me, you’ve been playing with IE7 since beta 1 and know that it’s appearance has changed drastically even through the beta stages. It’s look now is actually extremely slick in my opinion with some nice new features. The big three are RSS feeds, tabs, and PNG support. The RSS feeds are strangely modeled after the Safari’s RSS feed reader. This is actually a very nice way of reading through a feed. The searching on the right will prove to be more useful than you might think at first glance if you read feeds like the BBC where they get updated 50+ times per day and you still want to find something (or digg which is worse). It is a nice reader all around for actually reading the topics of the feeds instead of firefox’s where you can only see the titles (which I only see useful for things where the title can tell you everything or you want to read every entry). Tabs have been officially supported in IE with IE7 now and I think that this is a great improvement. I use tabs almost all of the time so this was a requirement. A lot of people turned to IE-based browsers like Avant or slimbrowser as an alternative or used the Yahoo toolbar for tab support. Now they are native and easy to use. People who use Avant and are used to Ctrl-n being a new tab (I still don’t understand why someone would pick n which everyone else calls new window…), you cannot remap the keys natively and will have to get used to every other browser in the world’s use of ctrl-t (or just keep using avant). The png support might not seem like much in comparison to the security updates, but I realize most people won’t ever realize the security updates are there and will probably see the png transparency support. Yes, this means things like google maps will actually look right now.

My opinion is that IE is better now, but it still offers little than another browser doesn’t already have. The biggest advantage in my opinion is still the security zones that Opera kind of has on a per-site basis, but none but IE have done quite as well. Past that, there are still a lot of add-ons for IE to get the features that extensions will get you in Firefox, but IE doesn’t add anything wonderful to draw me back.

Firefox 2 is another big launch just this week. Unfortunately in my opinion, it doesn’t change much. The tab support has been greatly improved to have a drop down for all of the tabs listed, a close button on every tab, and dragable tabs. Spellcheck is also nice now that it has been added to every textarea that you type in including webmail boxes, etc. The anti-phishing filter (probably stolen from IE7 which probably stole it from spoof-stick) probably is good to have, but I haven’t had the fortune to get to see something that it deemed as phishing. The updated interface is nicer than before, but themes are still probably what anyone who really cares about UI will turn to. The SVG support apparently was also improved, but I doubt that anyone will actually start to use SVG for quite a while.

In the end, these releases didn’t redefine anything. Most firefox extensions still work, are integrated, or there is an equivalent that exists. IE hasn’t pulled above anywhere, but it is closer as a contender.