Homepage

Integrated Feedback

November 9th, 2006

Its been a while since our last post, both Chris and myself have been working on other projects so have had little time to work on this application recently. I want to post about something I was working on a couple of weeks ago, integrated feedback. One of the main selling points of our application will be its ease of use and optimised work flows. To make our application as easy, simple and fast to use as possible we will require a lot of user feedback come alpha and beta testing time. While both Chris and myself have a lot of experience with user interface design, work flows and usability, we don’t know everything and we certainly don’t know everything about how our users will want to interact with our application. After all, a popular application is one that people want to use because it has the features they need and its easy and simple to use. User feedback will be essential to the success of our application and we want to involve users at a very early stage so that we can focus our development in the right areas from the start.

Getting feedback from users can be hard. Firstly, end users often aren’t the most technical of people, obtaining useful information from them can often be difficult at best. A typical feedback would be something like “I was trying to do blah and I kept getting an error”, from here you then have to contact the person and try to find out information about what they were doing at the time, information about their system such as browser and version etc. Often this information is hard to obtain and by the time you have it the user who submitted the feedback has often forgotten what exactly it was they were trying to do at the time. Another barrier for obtaining useful feedback is the hassle of submitting it, once a user has found and issue they want to submit feedback about usually they will usually have to go to your website, find the correct contact method, submit a report, try to find all of the relevant details about what they were doing, what page they were on etc. all of which is not something people will usually want to do.

We want as much user feedback as possible so we can make our application as good as we possibly can. To make it as easy as possible for users to provide feedback we are integrating a feedback utility into the application itself. When submitting feedback all a user has to do is click the feedback tab available on every page to reveal the feedback panel, fill out a couple of basic fields and hit submit. They never leave the page they are currently on and can carry on using the application without interruption to their work flow. This is achieved through submitting the form via AJAX. By having the feedback integrated into the application this allows us to automatically submit a whole host of other information along with the user feedback such as browser version, application and framework version, server information, the page the user is currently on, and any post, get and cookie variables.

In making it this easy to submit feedback we are hoping to increase the amount of feedback we receive as well as cutting down on the time it takes to obtain the information needed from the user. Also, by controlling the exact information we receive we will be able to identify common trends by running a few simple queries on the feedback database. If there is a bug that affects a certain version of the application, or particular server configurations we will easily be able to pick up on this and locate a bug or problem with the application.

Jamie | Details, Code, Planning, Choices | 2 comments

Version Control on OS X

October 19th, 2006

Version control is essential for application development when more than one person will be involved with the project if you want to avoid the nightmare of over writing each others files, and just plain useful even if you are developing on your own. Subversion is one of the best version control systems around right now. The great thing about it is that you can both work on the same file at the same time and integrate your changes when you commit them, unlike other version control systems that lock a file when someone is working on it which can be a total pain if someone forgets to check in a file and is not available.

I’ve been using subversion for some time now as coding takes up a large portion of my time, where as Chris, being primarily a designer, has had little experience with it. I wanted to find the best GUI for using subversion so that I could introduce Chris to the wonders of subversion. Both Chris and I run Apple computers so that narrows down the search some what. Here is a quick round up of subversion GUI’s I have tested (or tried to test):

• svnX - This is the software I have been using for the last few months. Its been relatively stable and provides a good feature set with a nice looking GUI. My only real complaints are that some of the more advanced functions are not that easy to work out how to do without reading the help files and there are too many windows.
• RapidSVN - Many people use this GUI, personally I find it a little slow on osx as its not a native application, I also find the interface a little clunky. In terms of how this works I have not come across any real issues.
• ZigVersion - The new kid on the block, its a little unstable at times and lacks support for some of the more advanced features but its early days yet. Looks very promising and could very well become the best GUI if all goes well for this app.
• SCPlugin - An OS X clone of TortoiseSVN, the website for this hasn’t been updated since 2004 so it looks like development of this has ceased. When I used it I found that it slowed down the finder to an annoying level so eventually had to remove it.
• Subcommander - This program might be good but I couldn’t test it as it crashed every time I issued a subversion command!
• eSVN - This program requires you to install additional software to enable it to run, once installed the window management on this application is so bad it makes it unusable. I gave up without even being able to add a repository!
• TextMate - Not a subversion GUI as such, but this has built in subversion support that works pretty well, it lacks support for some of the more advanced commands and I wish they had a menu for executing subversion commands. For quick commits while working on files this is great.

We are going to stick with svnX as its the easiest to use, fast, and there is a 1.0 update coming at some point which looks like it will be rather good. A word or warning though, if you upgrade to subversion 1.4 you will find that svnX is no longer able to work with your repositories. The 1.4 update has made quite a few changes to that way in which subversion stores it files, thes changes are not backwards compatible with 1.3 repositories. Subversion 1.3 and 1.4 server/clients will talk to each other just fine though.

Maybe Chris will post his thoughts subversion as a newcomer once he has had a chance to get to grips with it.

Jamie | Code, Choices | 1 comment

Post Production

October 16th, 2006

One of the first considerations for the application is what language to use and which platforms we should support. As this is going to be a “download and install on your own website” application rather than a hosted service, platform support is a key issue. Some of these choices were very easy, others decisions were a lot more diffucult.

Lighting the LAMP

LAMP (Linux, Apache, MySQL, PHP) was the obvious choice for us, firstly because I have the most experience with this set-up, secondly because there is a huge user base which will provide us with the most potential customers for the application. We are going to focus on Apache, MySQL and PHP, with the aim of supporting Linux primarily plus as many other operating systems as possible without compromising any features or having to write overly complex code. IIS will not be supported due to the lack of support for .htaccess which is one of our requirements for clean urls.

To PHP or not to er, PHP?

One of the decisions that had me hung up for quite some time was if we should go with PHP4 or PHP5. In the end PHP5 won this bloody battle mainly because I ran into a few issues while trying to use PHP4 which PHP5 solves very nicely. At first I wanted to use PHP4 so that the application would be compatible with as many servers as possible. I really didn’t want to restrict our application to people who have upgraded to PHP5. A quick poll of some of the top web hosts revealed that the PHP4/5 split was about 50/50. So basically by using PHP5 we cut out about half of our potential customers, not something we wanted to do for no reason. After many days of schizophrenic struggling with myself I eventually decided to go with PHP5. The programmer in me was saying PHP5 while the marketeer was pulling me towards PHP4. In the end the deciding factor was just a single character, “&”.

In developing the framework to run this application I wanted to be able to pass objects around between classes. One of the major changes in PHP5 is the way in which object references are handled. When you assign a variable in PHP4 the default is to make a copy of the object, in PHP5 the variable is a reference to the original object. If you want to read more about this see here, they explain this far better than I can. So this is where the “&” comes in, if you stick and “&” character in-front of your variable in PHP4 it will pass a reference to the original object instead of a copy. Great, no problem, apart from when you forget to add this little sucker and spend ages trying to find where the problem is. After doing this twice while working late at night I decided that PHP5 was the road for me, no more dirty little &’s littered around my code causing head aches.

PHP5 also has a number of other nice features that are going to help the coding process. By the time we release our application I’m sure PHP5 will have gained even more popularity so the user base will be less of an issue. Onwards and upwards…

The Framework

There are a vast number of existing frameworks available and after having tried a number of them I found myself wanting to write my own that worked exactly how I wanted it to. I’ve played around with a numerous frameworks on different projects recently including the “holy grail” of frameworks, Ruby on Rails. I do like certain many aspects of RoR a great deal, it just doesn’t lend itself to creating a web application intended for installing on your own server. RoR is not supported widely enough by web hosts at the moment, although this is changing pretty quickly. Even so, the number of hosts supporting RoR when we release our application and more importantly, the number of people who have experience with using it will still be relatively low, this rules out the Ruby language along with the rails framework. There are a number of PHP frameworks available, some of which look very promising. The problem is they just don’t feel “right” to me when I use them, some of them are overly complicated when compared to RoR. The best of the bunch, in my opinion, is the Zend framework which is currently in beta. It’s not a good idea to base and application on a beta framework that could be liable to changes outside if our control which rules out the Zend framework.

It has to be said I am very fussy when it comes to programming and using other peoples code. I generally prefer to write my own code rather than integrate someone else’s code into an application. I started tinkering a several weeks ago with writing my own framework, getting the basics hammered out was easier than I was expecting and I soon had a basic system working loosely based around the MVC framework model. I say loosely as I have dropped the traditional model style from the system in favour or putting all logic and validation in controllers. I’ve been tweaking, working, and extending the framework in spare time between projects and its coming along nicely. I’ll be posting more about the framework as it develops along with the application.

Jamie | Details, Code, Planning, Choices | No comments