One advantage to open source software is that it can be designed to fit specific needs, rather than building a huge project like an office suite. So we have taken a lot of time to build a software solution that we think will solve many schools' needs. And since it is open source, if it answers almost all your needs, it might be relatively easy to add, or get someone to add, whatever you need.
By making the program web-based, we gain several advantages. First, we can support almost any workstation over a local network.
Second, most users are very familiar with using their web browser, so we do not really need to teach them how to use the supporting software. In Belize, we have many users who are barely computer literate, so using their web browser makes it easier than a custom interface.
Web-based applications do come at a price, however. The basic structure is: click on something, browser sends a request to the web server, the web server sends back a new page, and the browser renders the page. While the delay is often not significant, it may not be instant.
There are other trade-offs, both positive and negative.
Incidentally, finding photos for our demonstration database was another problem. Try finding several dozen royalty free images of young people on the Web. We obtained what we could, and then "pixilated" them like you see on TV to protect their privacy. We are only trying to show that you could have your actual students' photos here.
It turns out this adds lots of complexity to the program, for a feature that many schools will not use. We may decide to change this to a more robust system. We want to continue to be able to support multiple schools on the same campus, but perhaps it would be better if each school had a different web access page. This should not require multiple copies of all the program code on the server (though it would not be a big problem if it did) but by keeping the data more separate we could make a lot of things easier.
This is a good example where a feature might sound good, be useful in certain cases, but a simpler approach might be better in the long run.
For Markus, we needed an unusually large authentication system. A school might want to deny or allow students to view their own grades and demographic information. Teachers could be allowed to enter and change grades for sections they teach, but not sections they do not teach. Administrators or department heads might need the ability to change any grade. And finally, a database administrator might need the highest level of authentication, to change things that require technical knowledge of the system.
We have found two problems relating to supporting multiple languages. The first is relatively easily solved. One relates to having program prompts, instructions, and help and other documentation available in more than one language. This is not too difficult. You can have one file for each language, where certain keywords are paired with a word or phrase in another language.
The nice thing about this is that if a school speaks a language other than English, all they have to do is find someone who speaks both English and the other language, make a copy of the configuration file, and substitute the words, phrases, and paragraphs in the intended language.The second problem is a bit trickier. This problem involves character sets. We used to use one character set that included the accented vowels and characters like *ñ* that are used in many European languages, including Spanish, French, German, etc.
This left out most of the languages of the world, including Asian, Middle Eastern, and other languages that use a wide variety of characters. So most of the world is going to UTF-8, which uses more than one byte for many characters, and can represent virtually all of the world's languages. The problem is that if any of the software pieces you use do not support UTF-8 well, you get funny looking characters. We have this problem in Belize, where the official language is English, but we have a large number of Spanish names.
In Markus, we have had to do a temporary workaround. We convert the common Spanish accented vowels and the ñ character found in proper names into two English characters to store in the database. Then we reconstruct them on output. Later, when the bugs in the chain of UTF-8 software get fixed, we can remove that workaround and store the proper characters in the database.
The problem, besides the fact that most web forms are rather ugly, is that each trip back to the web server takes a certain amount of time, though usually not long. However, it is very difficult to maintain your place with all the screen changing.
The result is that it is easier for a teacher to enter grades or for an administrator to make a number of changes at the same time. It more closely resembles the behavior of a regular spreadsheet, and enhances the overall experience.
We produce CSV files from Markus for each teacher. They import the CSV file into their spreadsheet program, like OpenOffice.org Calc or Microsoft Excel. They fill in the current grades, and then we import them back into Markus. This system works quite well, but it does require some work, usually by the computer science department, to make sure the teachers do it properly.
One of the strengths of Markus is that a user can sort and filter the data in various ways. If you need a printed version, you can, of course, print the page from your browser. Or you can check a box labeled CSV and produce a CSV file from that database query.
The CSV can then be opened in a spreadsheet and formatted and printed however you want.Special reports, such as Progress Report cards, are printed as PDFs. This makes it very easy for an administrative assistant to print the report cards, and also to print individual pages if the printing gets messed up or if the student loses their Progress Report.
We have not yet added the Transcripts reporting, simply because we do not yet have any schools with enough data to be able to produce transcripts. But the structure is in place, and transcripts will also be produced as PDF files. The ability to produce transcripts on demand is especially valuable here in Belize, where students sometimes have to wait a week for administrative personnel to copy the information from permanent records, and then risk possible copying errors.
Really good software should have excellent documentation. Some open source developers suggest that the documentation should be developed concurrently with the programs. I agree. I wish I could say that we have done it that way, but good documentation has yet to be written. It is on our TODO list, and we hope to have it before the next school year.
We also have not yet developed adequate packaging. Consequently, if you wanted to install Markus, you would have to go through a manual install process. Again, this is a weakness of the program, which we hope to have rectified by next school year.
Printed from linux.bz (Markus Design Strategies - Linux.bz, Linux in Belize)