The other day I came across an ad for an email marketing provider called GraphicMail. I clicked through to their website and was highly impressed, not only by the look & feel of their website, but also by what they have to offer!
The time has come when I need to use a third-party company to handle my newsletters. In the past, I always did all the bulk mail myself. I wrote my own mail scripts, ran them in batches, manually dealt with all the bounces, change of address notifications and out of office replies.
But I don’t have the time for this anymore, which is why in 2008 the WikiStudent newsletters fizzled out.
If I use GraphicMail, I will be able to send out 10 000 emails with one click! I think it is worth paying R200 per month for a service like this. The free alternative is spending half an hour every morning, sending mails in batches of 500 over 20 days.
So why am I looking into this at the moment, when I could be spending more time working on the wiki? Well, even though newsletters do not need to be there when the site goes live, they will be introduced at some point, so this has to be considered while planning. An example to illustrate my point: I see that GraphicMail also offer an SMS service. I need to decide before the site goes live if I want to send SMSs as well, and start capturing cellphone numbers from the beginning if I go this route.
One thing I keep thinking of as I go along is the terminology to be used. Certain terms must come to mean specific things, and we must stick to them throughout the site.
Some examples:
I’m not sure what to call “Modules” and “Module codes” though. My personal preference is calling them “Subjects” and “Course codes”, but I must be in a minority!
Even though this is a wiki and words can be changed at any time, there are certain words that must not be changed, such as namespace names, which will form part of permanent URLs. Here’s an example of what a link to a module page will look like if the namespace “Modules:” is used:
WikiStudent.ws/Unisa/Modules:TXN203D
In the link above, one can easily change the module name (e.g. to TXN203-D) but not the namespace name, so if Unisa stops calling their subjects “Modules”, well, that will be a bit of a problem!
Anyway, this is my list so far. Let me know if you can think of other areas where terminology needs to be addressed.
This is somthing I’m asked every now and again, and I’m still not able to give a definite answer. I know I can say that it won’t be before the end of May, because that’s when the new MediaWiki release is due. By the way, this is a very time-consuming project. I spend over an hour a day working on it, and have to wake up at 4am to fit it in my day. (I don’t really have time for this, so I’m making time!)
Another reason why it’s going to take so long is because I want to do a professional job. It’s easy to set up a content management system and get your website up in a day, but a site like WikiStudent needs a lot of planning, and I really want to do it properly.
To give you an idea of some of the work I still need to do:
Today I got an email from someone asking me when WikiStudent was going to be finished. I’ve blogged my estimates before, and even gave a due date for the wiki section, but no final completion date has been decided on.
Estimation is hard, especially at the beginning. I found an appropriate quote from a book I’m reading called Facts and Fallacies of Software Engineering. Another book. Yes, I’m an academic
Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.
That is so true! For example, my end of April estimate for the wiki section seemed realistic, but now that I’ve decided to incorporate the entire site into a wiki (and do away with the blog and Xoops CMS) the wiki is going to need more time as it is going to have more functionality than originally planned.
The positive side is, doing it this way will mean that the site will be completed a lot sooner. Only one CMS instead of three!
I want to wait till the next release of MediaWiki, which is due around the end of May, so it definitely will not be before then. I’m even thinking of setting up a test-drive MediaWiki installation this weekend, to let people experiment and see what problems they encounter and use it as a learning experience to build a better final product.