We started talking about this because we needed some way of managing our productivity. Most project management is for very complicated software development and we needed something more general. We also believed that the program should be brain-dead simple to use so that we would actually use it. There should be very few clicks for commonly used features like time tracking, and more clicks allowed for document management and invoicing, but it should still be quick and simple. Andy and I also wanted to be able to replicate some of the better parts of other applications we’ve come into contact with like Salesforce as future add-ons or plugins. I want to take baby steps though since I am the sole developer and thinking too large is the number one killer of a good idea.

Quotes and Invoices

The feature we wanted the most was quick and easy quote and invoice generation. We also wanted to be able to easily create invoices from quotes. I already made an Invoicing System for the Mason Media Lab, but that had a lot of very specific functionality. It would be great to create a system that is customizable enough to replicate that functionality and much more when set up properly, but that’s way beyond the scope of this initial iteration.

One function of that Invoicing System was PDF generation which I am certainly building into this application. It’s as simple as creating a view that outputs a PDF. The eventual goal is to make the PDF customizable, but creating an interface for that is way beyond the scope of this iteration. It would be much more feasible to allow users to create new templates that standard data is dropped into. Even this would require some amount of PHP knowledge, but it’s not terribly difficult.

Quotes should have version tracking. Every time a quote is updated, a copy is created and the changes between any two given revisions are noted automatically by the application. The user should be able to optionally add revision notes. This is mostly a tool for when the client asks about previous quotes.

Invoice items need the option of having an associated image. One of our larger clients had a previous designer who would present each invoice with a separate attached page with screen shots of work on it. We thought this was a very good idea and gives the client the impression you are going the extra mile for them. If any invoice items have associated images, by default the application will generate an invoice with an extra page that has them all laid out labeled by item number.

Some projects are invoiced as a fixed price for an item, others as hourly. This system should be flexible enough to handle both. For the case of single, package-priced items, it is nice to have it laid out on the invoice like so:

1. Huge freaking database application
   • Laundry counting, sorting, viewing
   • Statistics on different kinds of dirt found on garments
   • Garment owner tracking, sock pairing
   • Reporting by owner, garment, dirt. Export to CSV

Other Features

• User management with privileges
• Searching for… everything. It’s not clearly defined yet.
• Projects have categories (print, web, video, animation, mobile)
• Blanket discounts on invoices
• Tracking of total quote prices and total valid invoice prices for some basic accounting
• Hours tracking on projects, eventually per user
• Projects have statuses for tracking success

I should make it clear that this application is being developed to fit our company’s needs. We’ve been taking feedback from our clients of what they’d like to see in such a program and they’ve responded, but the following are features that are not in our initial plan:

• Time sheet API to interface with industry-standard and compliant time tracking to link that data to internal projects
• Create project templates
• Tasks can have documents associated with them
• Option to make single tasks or entire projects public or share via email
• Allow guests to upload these documents

And that about covers it. I’ll be writing here in the future with development updates for my own organizational needs and for anyone else who cares.

Basically the problem with any ORM is that it needs to have your database structure mirrored so that you can manipulate the data and build queries in a way that mimics the database itself without actually touching the data until the moment you need it. DM/DMZ have a rather verbose method of representing this with lots of nested arrays and it’s a pain, but after it’s set up, working with it is really decent if a bit too magical. So my odyssey has begun in creating the data structures as code. This post is not supposed to be about that, it’s supposed to be a transcription of my ideas and notes that I’ve been constantly referring to. So here we go…

We are a design company, not a software development company. Our needs in project management are a little different and often smaller, even when we do software development. The working title for this project is Yams. It doesn’t mean anything. No, it does not mean ‘Yet Another …’ it means the root plant that is orange and tastes very good when baked/boiled/whatever. My goals in building Yams are to start simple but generalize everything so it’s easy to add features later. Yams is designed for a group of people who do projects of any sort to upload it to their own web server, have a user account for each person, and manage responsibilities per user. Let’s break it down.

Users

Typical user system with privileges. It’s number based, 0-10 with registered users occupying 1-9, guests occupying 0, and admins occupying 10. I haven’t put much thought into this part of it yet but I have a vague idea that users will start at level 5 or something by default, most tasks in the system will require level 5 by default, but if you want more user classes you can define them as higher or lower and then change the required access level for tasks as an admin. This is all really nebulous and not planned out at all right now so let’s move on.

Accounts

We separate our projects into accounts. Accounts are companies or people or whatever that we do work for. They are not user accounts in the system, those are the Users from above. This is really a top-level object and lots of things will belong to them. Accounts do have an owner who is a User and a primary contact who is a Contact. On the account summary screen, the primary contact’s email and phone will be used. I’m not sure yet if it’s a good idea to also have a phone number and email for the Account itself, but if so then it’s a trivial task to add them. This object has a notes field that can be used to store miscellaneous data. This can be used as a crutch to store data that should go in custom fields. I want to make custom fields ala Salesforce a feature but more on that below.

Contacts

This object is a single person that we need to talk to when working on a project. Many of these Contacts may belong to a single Account. A Contact may even be linked to multiple Accounts, but that’s not a typical scenario. On the Contact edit screen, I’m thinking a drop down box to select which Account the Contact belongs to with a JS-enabled (+) button that adds a second drop down. This object stores a first/last name, full address, phones, and email.

Projects

A Project is a collection of tasks. It belongs to a single Account and has a primary Contact that defaults to the primary Contact for the Account. It may only use Contacts from that Account. Dynamically populated drop down boxes everywhere. Projects can belong to Categories. I won’t dignify Categories with a section, but Yams will allow users to add Categories in a rather standard system. Each project has a status: ‘Not Started’, ‘In Progress’, ‘Completed’, ‘Deactivated’. It also stores a start date and an end or due date. A notes field is present here as well.

Tasks

Tasks are a major workhorse object. One or more Users are assigned a Task as being responsible for completing it. Each Task has a start date and due date as well as an hours field that may be used initially to estimate project length and later edited to reflect how much time was actually spent. In the future this functionality will be much expanded, perhaps with a desktop app (AIR maybe) and hours will be broken down by user. Tasks can also depend on each other. A major goal of this application as will be discussed in the major features section is a timeline view for projects. There’s a fancy name for these graphs that I can’t think of right now, but Yams will do that. In order for the feature to be automatic and magic-cool, Tasks need to be structured in a tree of sorts. More on this in the features section.

Quotes/Invoices (Itemlists)

I want this system to enable rapid quote and invoice generation from a project or projects. Itemlist is the name for these objects since they are essentially identical. Itemlists are versioned, if you make changes to one it creates a copy and changes the creation date and invoice number if applicable. It marks the old one as obsolete and notes what Items you added or deleted from it as well as an optional revision notes field from the User. In addition to storing whether it’s an invoice or quote and if it’s a current revision, invoice Itemlists make note if payment has been received.

Items

Items are another workhorse object. They also have a tree structure that will probably be limited in the application logic to 3 levels. An Item belongs to one or more Itemlists. Items may be either independent and store a description or they may be an alias for a Task which uses the Task’s description. This allows Users to see if their project has been correctly billed in the end. Perhaps there will be a mechanism to mark a Task as not needing to be invoiced on the screen where projects are converted to invoices or quotes. Items also store an optional image file which is an image of that particular task. For design work on a small scale, a Project may consist of many Tasks that are themselves mini projects. I look to one of our biggest clients that has us do miscellaneous small design projects and each one would be one Task in this paradigm, which means this project would have multiple images, but each Task/Item need not.

Phew. That about covers the major structures as we’ve planned them out so far. I think I will make another post later defining the major features we want Yams to have and the rationale for each. I’m way too zazzed after those 1200 words to write decently in this update.

Since then I’ve taught myself some Python and revamped my video host with Django (Link). I hadn’t had experience with the MVC design pattern although I knew the theory. Django really drove the point home and forced me to use it. I had such a wonderful experience that I wanted to be able to code the same way in PHP, but after trying CakePHP and CodeIgnitor, I was still wanting. These frameworks tried to do too much. I just wanted something that would abstract the database stuff away for me and let me do my own thing with the controllers and views. Something really minimal. Now maybe there is something out there like that, but I couldn’t find it. Plus, I figured this would be a great learning opportunity. My initial plan is detailed below for my own reference and for others who may be interested.

Andy and I sat down and figured out what functionality we wanted in the project management system and thus the data we wanted to store. I created a schema on paper that is decently complex and will serve as a good test case for this framework.

I spent some time today thinking really hard about how Django does the database stuff and why I liked it so much. Basically it does the following:

1. You define a number of models that extend the base model class
2. You run a script that automatically creates tables in your database from these models
3. You access all your data from an object, run filters, and sort using methods in the base models class
4. All this time, the model has been building an SQL query which is not executed until you access the data itself. It can do this because it knows the structure of the data in the database.

That last point is very important. I have to somehow create a way to codify the database schema that can be parsed by the framework to build SQL queries without hitting the database to take a look. There are a few possibilities for doing this using the PHP language, but short of porting the functionality of the Django Model base class over to PHP (which might not even be 100% possible), there was no way to create an easy-to-read and semantic schema in the PHP language itself. So I’ve created a parser that takes an INI file and creates a schema from it. The format follows:

[<table_name>]
<field_name> = <type>(<default_value>)[,unique][,index]
<foreign_key> = fkey(<foreign_table>)[,array]
<enumeration> = enum(<value1>|...)
...

can be one of ‘string’,'text’,'integer’,'float’,'date’,'boolean’. array is an optional parameter on foreign keys to indicate that there is a many-to-many relationship between the two tables.

An INI file. Cute. I’ve created a parser that dumps all this into a multidimensional array in the form

$structure = array("table1" => array(Field, Field,...), "table2" => array(Field, Field, ...))

where Field is a class that is little more than a struct to hold useful information about a field. I don’t know if this is the best way to proceed, but I’ve got a pretty good feeling about it. My goal is to create a Model class that can be passed a table name in the constructor and can use the information in the structure array to build queries. My next step though is to write the function that builds tables in the database from the information in the structure array so I can standardize how it will handle pivot tables and other stuff I haven’t thought of yet.

I intend to update this blog more regularly in the future with further developments with the project management system which entirely too long of a title. We’re working on it under the name Dorsia but that will absolutely not be the final name. We’re thinking YAMS (doesn’t stand for anything, or maybe we’ll invent an ironic recursive acronym) but really it could be anything.

I received an email from Dreamhost last week informing me that they were throttling connections to my video hosting site because recent traffic spikes from the Sonic Unleashed Let’s Play were causing the Apache server to have problems. Now I’ll be the first to admit that my video hosting solution is not elegant or efficient. I started it small and hacked on features as I went. Yeah, one of those. Everyone makes one eventually, but in this case, mine got popular so I needed to fix it.

I determined that I needed to implement a form of caching to cause my spaghetti code to run as infrequently as possible. Professional-level caching solutions require control of the server the site is running on, both hardware and software. These same solutions are also rather complicated and work to cache selectively only those parts of the site (and sometimes within individual pages) that do not change very often or ever. For my site, I know that once a video is added, the page that lets you view it almost never changes, so this is the part of the site that will be cached. This is also the part of the site that sees ~80% of the traffic total and closer to 100% of the traffic during the spikes. Fantastic.

The rewrite involved a few steps. First I removed all the code used to draw the page contents and put it in a function. The function, printVideoPage, takes the ID of the video in the database and returns a string of the page content. I also took this opportunity to optimize the way I use ADOdb because I have a better understanding of it now than when I wrote this 3 years ago.

The second function I wrote creates a cache file. This function, updateCache, also takes an ID. It opens the cache file located at the configured location with the configured file name and starts writing. It actually writes a PHP file which declares two variables, $name and $contents. When show.php includes the cache file for the requested ID, it can put the name of the video in the title and the contents where they belong.

For the average visitor to my site, this eliminates all SQL calls and a great deal of very bad PHP. If a cache file does not exist, the site displays an error. This means that the cache must absolutely be a correct and accurate representation of the database at all times which annoys me, but as long as I call updateCache any time I change or add a video record in the database, everything should be fine. I do not think there are any bugs, but there are certain aspects which have not yet been tested as much as they should be. show.php is functioning as expected which for now is the most important thing.

I cannot show you empirical evidence that my measures to reduce load have worked. I’m on shared hosting; I don’t get access to that kind of stuff. I can only hope it has made a difference and that Dreamhost sees that and unthrottles me. If that’s not good enough for them (and it really should be, Sonic 2006 had way more traffic and this didn’t happen), I am at the end of my bag of tricks on the current codebase and I will have to rewrite. Ughh.

I was poking around the internet and found the solution on another page at our university. I believe it was created by our competition, Creative Services, who we’re pretty sure take templates and butcher them to be Mason-branded. The implementation on that page was the answer no matter how much I loathe their cookie-cutter techniques. The answer is <body> classes.

In the past I had dismissed body classes as being a poor design strategy for a site. This was because I’d only ever seen poor implementations of them, parroted by Lynda.com. You should not use <body> classes automatically on every site you design. This encourages inconsistency in design between pages. It also bloats your CSS because if you’re using a <body> class, you’re using a lot of descending selectors and creating styles like .bodyclass #sidebar ul li.

But there are circumstances in which body classes can be used correctly and one of these circumstances is my problem. The idea is to first create your page without any JavaScript functionality at all, but with JavaScript functionality in mind. That carousel of images, for example, becomes a grid of images. The scrolling news shows only the top three items. The animation is not present. Then in your $(document).ready() block before anything else, you do this:

$('body').addClass('js_ready');

You’ve just added a class to your body tag with JavaScript. If the user does not have JavaScript enabled, this will not trigger. So now you can put all your JavaScript styles under the .js_ready selector. Because of the specificity of CSS, adding more information to an element selector will override any other reference to that selector. So if you have #carousel ul li and .js_ready #carousel ul li, any styling in the latter block will override the former, making your page style differently in the presence of JavaScript. This may necessitate updating the prepackaged CSS that came with your widget to include the body selector.

Well that’s a pretty cool thing, and while I was realizing how it worked I thought of another possibility. Admittedly it’s not going to be widely used, but I guess it could make a good tech demo. What if you want to have different themes for your page? Each theme is under a different body class and could be changed via JavaScript. I imagine this would be most handy if you’re pitching to a client and you’ve created a couple different designs and you wish to cycle quickly through them for comparison. The theme change would not be persistent across pages without some extra work, and who wants to create more than one completely realized style per site anyway? But it was a neat idea I had. Maybe I will implement it here on Disco Shiny…

Being a central database for all our services and all jobs we’ve ever done, it becomes easy to update information regarding our services and have them take effect immediately. It has occurred to me, however, that this could be very bad for invoices we have already submitted and been paid for if, say, we changed the price of plain paper. Those completed invoices would suddenly change. I’ve decided the answer is serialization.

When we submit an invoice to accounting, it changes status to “Submitted” (or it will when the admin section is up and running). At this point, we don’t want the invoices to change any more ever, so we load up an invoice in our Invoice class and call serialize() on it. This makes it a string which we then store in a new field. Upon loading an invoice, the class should check a) the status of the invoice and b) if the serialized field is populated. If the conditions are right, it replaces itself with an unserialize()‘d version of the invoice.

I’m just glad I thought of this before I started coding the admin section. If all goes well, though, nothing should change from the perspective of the parts of the application using the class. It just seems like something that could have easily slipped under the radar and then never gotten fixed because we don’t change our prices often at all and I would be gone the next time we did it.

The Front Page

• XHTML
• CSS
• PHP
• MySQL
• jQuery/AJAX
• PDF Creation

Limited Demo

One major project I’ve been working on has been replacing the person who’s job it was to aggregate all our invoices, send them off to accounting, and report our numbers each month. Her system comprised a number of excel spreadsheets between which she would copy all relevant data. Naturally a database is a much better solution and so I set about creating one. The project is not yet complete, I still have to create the administration section. Most of the framework is in place, though, and the front end is what I consider to be beta status.

This project was a vehicle for me to learn JavaScript. Since our previous system of creating invoices was entirely based in Excel, the new system had to have at least as much functionality. This meant creating a rich web application which would carry out the calculations for costs automatically.

Using jQuery has allowed me to do a number of things with the site that are both aesthetically pleasing and highly functional. The page that allows users to search for and filter invoices, for instance, uses hidden form inputs combined with a table to simulate rich checkboxes. Clicking a table cell highlights or normalizes it, indicating that it is active or not. The actual form element is a hidden input for each table cell that toggles between ‘off’ and ‘on’ through the use of jQuery.

One very important feature of the new system relates to the way we are paid as a university organization. Each organization has one or more fund numbers which they can supply as a form of payment, and funds are automatically deducted when we submit the completed invoices to accounting. Unfortunately, these are simply numbers and are rather non-descriptive. This invoicing system uses PHP/cURL and AJAX to look up the unit name tied to a given org number so we can double check with clients. We have since caught three instances of clients giving us entirely the wrong department’s number.

The system is incomplete, as I have said. I am actively developing it and hope to have it deployed in beta or gold status by the next fiscal year. At this point we intend to start shopping it all over the university to other organizations that provide services within the university. This is highly tentative and should not be taken as official word.

This is a trap. I fell for the trap.

A large part of the web designer’s job is to translate a mockup of a design from Photoshop or something into HTML/CSS. This means looking for logical divisions of content and thinking about how the box model can help you achieve this layout. When I created the current design, I saw two columns separated by the fake 3D effect and said “Ah! I will have two columns! One of them will have the repeating background trick and an image each at the top and bottom!” Easy to think, impossible to implement. First off, the sidebar needs to scale with the content, or the 3D illusion is broken. And thus begins my descent (the highest form of patriotic) into the trap. I turned to JavaScript.

All I need to do is grab the heights of the sidebar and content, find which is bigger, and resize the other! Oh, but I need to take into account the offset. Oh but I need to move that bottom image as well. And after not too long, I’ve created something that functions. Hooray. Unfortunately, this is a problem for a number of reasons,

1. It is highly inelegant. It’s overly complicated and the browser should be doing it for me.
2. The syntax highlighting code breaks it because it takes longer to execute
3. It can be easily solved in CSS with a little more creativity

Look, all that needs to happen is have the content div be the combined width of the current content and sidebar divs, images at the top and bottom (use an inner footer div that clears both and has an image background), and then have the two columns with no image backgrounds just take up however much height they need and let the browser sort it all out. That’s what browsers do best.

I got caught up in the shine. I saw what JavaScript could do and was tempted to make bad layout choices by the fact that JavaScript can be used to crutch almost any situation. Learn from this. Think long and hard about each thing you want JavaScript to do. Can it be done no other way? Could you handle it in either the PHP/ASP/Perl/Python or the CSS? Because you should. Here are some things which you can and sometimes should use JavaScript for:

1. Animation. This is a whole can of worms, another post maybe.
2. AJAX and all that cool web 2.0 stuff
3. Form validation. Can be used with number 2

If it’s not one of those things, think again.

This post brought to you once again by the <ol> tag.

Monocle Radio

• XHTML/CSS layout
• PHP
• MPD class for PHP
• MySQL for user management
• Icecast2 streaming server

Monocle Radio is a front end to Music Player Daemon, an application for Linux that does exactly what its name implies. The only way to use it is to run a front end, such as Monocle Radio.

SourceForge Page

In my freshman year of college I had an old computer I used as a server. I kept some backups on it as well as my music. I wanted to be able to listen to my music even when I was not in my room, so I decided to set up a streaming solution.

I looked into available solutions and at the time all the software I could find was either incomplete or too complete. My server was not powerful enough to handle Ampache, for instance. It was for this reason that I decided to make a web-based interface to suit my needs. I wanted something no-nonsense and responsive, even on my aging Pentium 2 box.

My roommate and a couple other people I know wanted to be able to listen as well and have control when I wasn’t using it, so I implemented a multi-user system. It was not very secure and focused more on getting the job done. It required users to be logged in to change the playlist or control the playback, but anyone could listen.

At its completion, Monocle Radio fulfilled my needs. I released a couple bug-fixing releases, but have since ceased development. I no longer maintain a server for my music due to bandwidth and power constraints. Also the old server was 2.5 feet tall and weighed well around 40lbs, an impractical machine at best.

• Transparent PNG support
• z-order
• Rounded corners
• Floats and margins
• Expanding boxes

Okay that’s all I can think of off the top of my head. The point is though, that none of these things are strictly necessary for a website. It’s easy enough to create a site that looks pretty much the same in IE5.5+ and the Firefox/Safari/Opera crowd, but if people choose to use a more modern browser, including newer versions of IE, the site will only get shinier.

Point of all this is, the people who don’t like IE and actively leave out fixes for it are not really professional level yet. Professional level developers neutrally regard or hate every browser equally. Firefox 2 has some weird layout issues, for instance, on sites that look fine in every other browser! CSS 3 support is still handled differently by everyone, each browser supporting a subset. The list continues.