Markus Design Strategies

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.

Web Based

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.

Familiar (Web Page/Spreadsheet)

We try to use navigation models users find often on the Web. This helps avoid the "what do I do now" puzzle. Also, most users are familiar with using a spreadsheet. By making use of tables that resemble spreadsheets, we add still more familiarity.

Student Photos

Part of the services we offer to schools in Belize is making their school ID cards. Since we already have digital images of all students, it seemed natural to allow Markus to include the student's ID photo on a web page with the student's current grades. We believe this could help avoid errors such as changing the wrong student's grade. It might also be helpful to administrators or counselors who may not know the student well.

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.


Using standard networking security tools, we could restrict Markus access to just a single server, a local network, a wide-area network, tunneling, or whatever. We anticipate that eventually we will have a school that wants parents to be able to see their student's grades from their computer at home. With proper security, that would be possible.

Multiple Schools/Divisions

We have several schools in Belize that have a high school and a junior college on the same campus. When we started designing Markus we thought it would be nice to be able to log in to any number of schools or divisions from the same login screen, using all of the same program.

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.

Authorization Levels

Many applications require some kind of user authentication. They might need to authenticate regular users, and some kind of administrative user with additional privileges.

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.

Multilingual Capability

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.

AJAX for Simple Editing

The classic way of entering or editing data in a web-based application is through forms. You see the information in a table, then indicate you want to edit it, wait for the page to show a form, then fill in the information. You then click something like a Submit button, and the data is sent off to the web server, the database is updated, and then you see your table again with the information changed.

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.

Asynchronous Javascript and XML (AJAX) is strategy that allows your current web page to send a request to your web server, receive a response, and update your web page without having to refresh the entire page. In Markus, we do not actually use the XML part, but most people call it AJAX anyway.

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.

CSV or Online Input

Our original intent was for teachers to go online (perhaps on the school's Intranet) and enter their grades. We also allowed the schools to choose instead to enter their data in a batch process through a Comma Separated Value (CSV) file. So far, the CSV entry has been more popular.

We produce CSV files from Markus for each teacher. They import the CSV file into their spreadsheet program, like 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.

CSV or PDF Output

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.

Documentation and Packaging

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 (Markus Design Strategies -, Linux in Belize)