Here are some screenshots of Magna CRM.

Click to open large images in a new window

This is a list, displaying Accounts. The top menu (tabs) and right sidebar are the standard navigational controls. Some things in the right area change (history cycles, some links appear / disappear etc) while the top menu is more or less fixed.

This is a form displaying a Contact. Following are lists of related records like Tasks, Issues, Past events etc.

I hope to post more screenshots tomorrow and maybe annotate them on how things work.

I am very, very close to finishing this! All features for v1.0 are done and now I am doing some miscellaneous tasks plus testing. I believe the beta version will be released by the end of this week.

Version 1.0 can probably be released before the end of the year, although that may not be the case for other reasons: I still need a logo for Rapid Signal, a new site design, maybe an additional layout for Magna, a shopping solution, maybe a tour, certainly an online demo etc

But I feel good right now. I’ll probably publish some screenshots tomorrow.

I wrote a draft of this post some time ago titled “To do or not”. Now I’ve finally made up my mind. These features are moving to a later Magna CRM release:

• Mail client and mailbox integration: This will probably be one of the first to implement after I release v1.0. The point is to archive mail you exchange with your clients / contacts. This is not very simple to do and requires a full blown mail client (for writing / answering an email), and integration with a mailbox (to read mails that go to specific mailboxes e.g. sales@company.com). Integration with Outlook would be nice too ;-)
• Custom fields / form designer: A CRM application is first and foremost a data repository. So, it will be needed at some point to let the user define custom fields, design his forms the way he wants them (placing important fields on top etc) and of course get reports based on these custom fields.
• Labels / Tags / Keywords: Because with tags I can advertise my application as Web 2.0 compliant ;-) Well, the real reason is that tagging accounts, contacts, leads etc seems like a good way to organize them. Of course I would have to try it to see how it feels, especially if custom fields get implemented (as you can certainly organize things using more and more custom fields).
• API: I really believe an API is important. It’s also hard to get right, as I found out while experimenting. Although an incomplete API will probably be included in v1.0, the full API will have to wait some more.

I really want to finish Magna soon, even if it means I have to cut some (many) features. And I still have a lot of work to do before v1.0 is reached.

One of the things to take into consideration when developing a multi-user application is the Database performance.

When developing PHP applications, I always use ADODB to provide a Database abstraction layer. More specifically I use my own DB layer, build on top of ADODB, but I only do this is to make it easy to replace ADODB if the need ever arises (e.g. if it stops being maintained).

ADODB has a great module (part of the standard ADODB package) called Performance Monitoring Library. This little gem provides some great functionality and I suggest you check it out.

An SQL logger and analyzer is provided, among other things. The SQL logger, when enabled, stores all executed queries in a DB table, along with some interesting data, like the time it was needed to execute the query. The SQL analyzer gives you 3 extremely useful reports:

• Suspicious SQL: The queries with the highest execution time
• Expensive SQL: The queries with highest total execution times (number executions * average execution time).
• Invalid SQL: Queries that produced an error.

During development I leave the SQL logger constantly on and use the analyzer reports to either optimize my queries or find ways to reduce the number of executions. Warning: Be careful not to leave the SQL logger on by default, because in real installations it can reduce performance. Also the analyzer will take a very long time to analyze more that ~500k queries. Anecdotal: I once left the SQL logger enabled in a health related project running in a hospital (~40 concurrent users, 24×7) for about a week. The analyzer never returned any results for the ~5 million records it had logged. So I had to discard the logged queries and leave it running for exactly 1 day.

Since I’ve made extended use of the Perf library with some really good results in the past, I have integrated it into Magna CRM. Through the use of a single flag (DEBUG_LEVEL) I can do various things like enabling the SQL logger or displaying the SQL analyzer screens to an administrator. I will leave this in, in case I ever need to find what’s wrong with a specific installation that has performance issues.

Magna CRM has a lot of lists. Actually the main interface consists of tabs (Accounts, Contacts etc) that take you to corresponding lists. These lists can be navigated using filters, a letter index (All, A, B, C, …) and paging.

I implemented state saving for these lists. So, if you e.g. set some filters, go to page 4, click another tab (or insert a record or close the browser) and then return to the same list, you will be at the exact same point (same filters, same page). This was applied to all lists in the application.

While it’s a very nice feature in general, it has a small problem: you sometimes get surprised when a list comes up with preset filters and all, because you have forgotten when you did it. I can’t think of any clever way to avoid this (timing out the state information is not a good solution), not that it’s a big deal.

I use Javascript to give feedback on missing required fields and invalid data (bad numbers, wrong dates, out of range values etc). Before sending user data to the server (where they are validated again of course), a function checks all fields for errors and if any are found, it reports them to the user and sets the focus to the first erroneous field.

So the user would see a javascript alert with something like this:

-Title is missing.
-Start date is missing
-End date is invalid
-Quantity is not a valid number

After clicking OK, focus would move to the “Title” field. The problem here is that the user must remember all other errors or press “Save” again to see the list of remaining errors.

So I did a minor change to the validation functions, so that the erroneous fields’ border color changes to red. This is much better but lets say the user fills the “Title” and hits “Save” again. The title’s border color must be changed back to what it was. The easiest way to do that was to set the border color property to an empty string. This removes the red color and redraws the field using the appropriate CSS. So most checks use this approach:


if (elem.value == '') {
err_txt += ('Missing value\n');
[some irrelevant stuff]
elem.style.borderColor = ‘#aa0000′;
} else {
elem.style.borderColor = ”;
}


I am not sure the empty string is the “correct” way to do this, as the w3c DOM spec doesn’t define what happens in this case, but it works in IE, Mozilla and Opera.

One thing I had to take care while developing Magna was i18n / L10n issues.

With i18n I mean the support for different time zones, date and number and currency formats (what Windows refer to as Regional Options). With L10n I refer to the actual steps needed to offer a translated version.

I want to make sure Magna works in any environment (because your host may be located anywhere in the world) and with at least 3 different databases (Access, SQL Server and MySQL). So, I rolled my own solution, learning a lot in the process. The biggest problem was probably time zones (and DST - daylight savings). The obvious solutions was to keep things in the database in a common format and encode / decode values, based on user settings, when reading or writing to the database.

The results seem good and now each user can select these regional options:

• Timezone
• Date format (DDMMYYYY, MMDDYYYY etc)
• Date separator
• Week first day (Sunday, Monday etc)
• Number decimal symbol
• Number grouping symbol
• Number decimal digits
• Currency symbol
• Currency symbol placement (left / right)

For dates, numbers and currencies the solution was straightforward. A simple pair of functions for each was enough (encode / decode). Dates (and timezones) were more difficult to handle. I am writing an article on this issue and I hope to post it in the next days. Localization issues are also a good subject for a separate article which I also hope to write soon.

With online maps becoming so popular after Google Maps (not that people didn’t use them before, but it is my understanding everyone knows about them now), I had decided to put a “show map” link wherever an address is displayed in MagnaCRM.

So today I added this feature. These “show map” links, open in a new window, calling a specific php script and passing it all available address data (address, city, zip, region/state, country).

The problem is what to do with these fields. Although I created an easy way to define which service you want to use (by defining the url), which fields to pass and with what name, it’s still not working perfectly.

Google maps always locates a US address and almost always a UK one. Searches for other countries don’t behave well, even though satellite images exist for them. So searching for “address, athens, greece” shows nothing, while searching for “athens, greece” gets you a nice, detailed map of Athens. It would be nice if Google would try a little harder to at least guess the city or country.

Mapquest is better in this regard. If the address is unknown, it will ask you if you want the map of the city or country. On the other hand, Mapquest needs different fields for US maps and rest-of-the-world maps.

Anyway, the best results for non US / UK countries probably come from local mapping services. So I now have to implement country based service selection. I hope this gets better results for everyone, without having to change any settings.

For MagnaCRM, I use FogBugz for to-do lists and bug tracking, replacing the wiki I was using before. Now I use the wiki for personal stuff only.

So, today I cleaned up my lists (features and bugs). A lot of things had crept in there (notes, thoughts, weird feature ideas etc) and I also found some duplicate entries. After two hours, it feels neat again! Naturally, some things moved from v1.0 to v2.0 and vice versa :-)

Undo in web applications is not very popular. Actually, I have used no web app that had extensive undo capabilities. I was reading about this recently somewhere and started thinking if I could make an undo feature for MagnaCRM and how I would go about implementing it. I certainly don’t intend to do it for v1.0 as I already have a full plate.

I think the most difficult operation to undo is a delete, because deleting a record may require deletion of dependant records (e.g. delete an account and you also delete all related contacts). Moreover, instead of deleting from the database you must only flag affected records as deleted. The good thing is that I can offer undo for delete operations easily, since I already have a Recycle Bin feature (deleted records go there and you can undelete them at any time).

Edits seem easier to undo although they could prove to be trickier. You need some kind of auditing mechanism that logs all changes done to records by each user. Then you use that to go back to previous states and you could even offer a redo.

The question that I needed to answer is: should I offer an undo feature that will only undo delete operations or leave it all for next version? I’ll probably do the later, as it will be rather confusing to have an undo button after deleting a record but not after editing it! For v1.0 the Recycle Bin will have to suffice: you can still undelete something even if no convenient undo button is offered.

Here is an interesting problem:

While using an application you edit a record with the intention to change the value in a drop-down list. Available options are A, B, C and B is currently selected. So you change that to C and save. Now, you change your mind and try to make it B again, but option B is now missing from the available options.

Here is why this happens: the admin has edited the available options for this drop-down list and removed option B. Records using this value still show it, but after selecting a different option there is no need to show it again.

Of course this is way too unfriendly and weird. I could only think of three solutions to this problem:

1. Do not allow the admin to remove options used by at least one record. The problem here is that if the admin makes a mistake while creating options, there is no way to fix it other than manually editing all records using the particular option.
2. Make the admin select an option that will take the removed option’s place. E.g. “Remove option B and put option C in all records using it”. This is not always easy: imagine a field “How did you hear about us” with starting options “Internet”, “Magazine”. Now the admin wants to remove “Internet” and add “Internet: ad”, “Internet: web site”, “Internet: search”. He can’t really replace the old option with one of the new three.
3. Add a small descriptive text to removed values. So the user would see these options: “A”, “B [removed]“, “C”. This way, no one has decided the new value for him and he is informed that option B is now deprecated. He can either select a new value or leave it as is. Moreover the admin has no problems in removing options.

I went with the 3rd solution which, while not super user-friendly, is at least flexible.

In all projects I’ve done, I always hated doing the administrator’s forms. And it’s all I’m doing these days for MagnaCRM.

I really would have left it as one of my last tasks, but I got fed-up having to manually edit the DB each time I wanted to make a change. So I pushed the relevant to-do items at the top of my list. Basically it’s user management (add / edit / disable / enable users), look-up tables (again add /edit / disable / enable records) and application wide settings.

Well they’ll be finished at some point and I’ll move again to more interesting things!

I have tried really hard to make all screens compliant with a resolution of 800×600. I don’t know what percentile of people use that resolution but I believe it’s not negligible. So, at least one template (just a special CSS really) will be aimed specifically at 800×600 users.

Now, I have reached one screen where I can’t fit in 800 pixels and do it gracefully: the month view of the schedule. It has to display 7 horizontal boxes, one for each day of the week, plus the sidebar. Since the real horizontal space I have is 760px (800px - browser’s scrollbar and border) and the sidebar is 160px I only have 600px left. That’s about 85px for each box, which really is too low. Things I tried:

• Removing the sidebar on the month view. Not good because the sidebar has useful information, plus navigational elements. Moreover it’s disturbing going from any other screen to the month view and vice versa.
• Displaying the days one under the other. Very bad, it doesn’t resemble a month view any more. It looks like a list.

So I am leaving it like that for now (in 800×600 either the boxes overlap with the sidebar or a horizontal scrollbar appears). If you happen to have a good solution in mind please advice!

While using FogBugz I noticed that textareas grow as you type in them. I thought this was quite cool and useful so I tried to mimic it for MagnaCRM.

FogBugz implementation was a little specific to their needs and I needed a more generalized way of doing it. This article was a good guide (it seems FogBugz solution is based on that too) and with some customization I managed to make it work as I wanted.

Of course the hardest part was making it behave nicely on all browsers. Although I am against browser detection techniques (when that’s possible), the code handles IE differently than all other browsers. Opera was a real pain and it’s not working as it should after all (the textarea grows at once to the maximum row number allowed by my script). It’s not really my fault, as Opera should not try so hard to pass as IE if it doesn’t really support the same features. Moreover I haven’t tried it on Safari, as I don’t have a Mac. I hope it handles it well!

Finally I should note that while I thought this would be a 5 minute hack, I ended up spending almost an entire day, trying various ways to achieve the desired effect and browser compatibility…

It’s being some time now that I have the final logos for MagnaCRM and Rapid Signal. I had the chance to show them to quite a few people since then and here is the verdict:

Most people like the MagnaCRM logo. Although it was pointed out to me that swooshes are much overused, the fact remains that most people find it professional and matching for business software (CRM software in my case). On top of that I like it a lot ;-) In any case, if you are of a different opinion, now is the time to speak up. Please don’t be afraid you’ll hurt my feelings or anything!

The story is different with the Rapid Signal logo. Most people find the logo bad, with explanations ranging from “too cluttered” to “ugly unidentifiable collection of pixels”. More over, through a comment on this blog, I was informed of suspicious actions from LogoWorks (selling logos stolen from other designers). You can read more on these posts by thepreparedmind.com: Post I, II, III. So I have to admit that my decision to go with LogoWorks was wrong.

Now, based on the reactions and my personal dislike of the logo, I decided to just drop it and go with another designer. This time I will go with a single design firm. I don’t really believe single designers are guaranteed to offer better results than services like DesignOutpost, Guru.com or even LogoWorks, but I want to see the difference in the experience.

The only upside to the whole story, is that now it’s easy to replace the RS logo. It would be harder to decide something like that in a year or so.