In this post, I will go over how I approached building a dashboard for a Corporate Intranet. For those who have read some of my earlier posts, they will know that I have been working on a system to capture and display MindTouch download statistics.
As somebody who has programmed primarily for terminals and auto-graders, the process of creating a dashboard was a challenge. My approach was to first break down the dashboard into smaller, more manageable pieces. I have come up with these three steps:
Displaying the Data – Trying to dump massive data sets and expecting people to look through them is asking for trouble. It is usually much better to display the data through charts and pretty tables. MindTouch includes some features to help speed this process along such as Google Charts, Visifire Charts, and dynamic tables.
Finding the Dimensions – The purpose of this step is to figure out how many permutations of the data there are. By knowing this, it makes it easier to create a dashboard that does not overwhelm the user, but still contains all the desired information. A dimension is essentially an option that when altered will change the returned data. The simplest example of this is time. Using the project that I have been working on as an example, if I wanted to chart the number of downloads, I need to know when the data should start and when the data should stop. So in my case, time is a dimension that can be removed. This step is especially important for more complex data sets, taking a look at the download statistics:
3 charting choices X 3 editions X 3 os X 11 flavors X 4 platforms X 2 servers X 5 versions = 11880 different graphs!
Laying out the Information – After removing the extra dimensions from the data, what should be left is a base set of data that can serve as a foundation for the rest of the data’s permutations. This basic set of data will be representative of the possible data so it is a good placeholder for designing a layout to present the data. When designing the layout, it is important to remember that there will likely need to be a space left open for an option bar (I discuss this further below) and that everything should fit on one page without too much scrolling. The goal of the dashboard is to present a simplified and user friendly interface where the end user can efficiently and easily get the information they are looking for. If the data set just calls for more then one page because it is too long to fit on one page or it just makes more sense on separate page, MindTouch has some useful features to help merge multiple pages into a single one. Look into things such as tabs, accordions, and web.toggle.
Adding Functionability – In this step, the goal is to add back the dimensions that were removed earlier. Now that the layout is done, we are going to add the ability for the end user to access the dimensions that were removed earlier. There are some fancy options out there, but for my project, I used a simple post form, but slicker menus are also available. MindTouch offers some excellent features for handling query parameters with DekiScript (See DekiScript globals). I used these as parameters in the Download Statistics extension which allowed me to, through the use of a simple form, manipulate which dimension in the data set was returned.
Using these steps, I created a dashboard which harness the power of the Download Statistics extension without burdening the end user with memorizing method calls. The final product is clean, simple, and most importantly, presents the multitude of data in small, digestible doses.
The final product:
Before I start this comparison between MonoDevelop and Visual Studios 2008, I have to first say that I am in no way an expert at either of these IDEs; I have spent a scarce 2-3 weeks with either, so take what I say here with a grain of salt.
The first obvious difference between the two IDE’s is the operating system that they run on. MonoDevelop is currently stable for only Linux. There are preview releases for Windows and OS X, but I did not have a chance to try these; I was using Ubuntu 9.04 running MonoDevelop. Visual Studio on the other hand runs on Windows.
The first thing before coding with any IDE is getting it installed. With MonoDevelop and Ubuntu, it was an apt-get away. The MonoDevelop package is fairly small and installed without much of an issue. The whole process took less then 30 mins. A problem did occur when I tried to start MonoDevelop up. Not quite as stable as I would have liked, but after a quick reinstall, everything worked.
While, even including the reinstalling, I could start getting to work on the same day with MonoDevelop, Visual Studios 2008 required a full day to install. I installed Visual Studios via a MSDN DVD. This caused my laptops DVD drive to whirl and whine for the next 3 hours. I stepped away from my desk while it was installing so I can’t say exactly how long it took to install, but I couldn’t have been much less then 2 hours and 45 minutes. Maybe I shouldn’t have also installed a full set of local documentation, but I was too afraid of canceling and having to start the installation over to find out how much faster it would be without the documentation. After finishing installing, it took another 3 hours to update to SP1. I am pretty sure Visual Studio 2008 updated takes up more space then all but the most meaty computer games out there.
In terms of look and feel, the two IDEs are very close. If there were any lack of menus from one to the other, it is probably only just hidden away. Projects and solutions also work well from one to the other, especially so with MonoDevelop 2.0 supporting the .csproj format.
The first glaring difference between the two is the amount of online help that is available. Traffic for MonoDevelop is at least a tenfold fewer then Visual Studios, so when a problem arises, it is very possible that the Internet holds no solution for it. The other issue is that documentation is not always up to date which has caused me several headaches while looking for non-existent configuration settings.
Alternatively, Visual Studios seems to be used by everybody. Whenever I had an issue with the IDE, which are already fewer then MonoDevelop, a quick google search brought up multiple solutions. If I had an issue in Visual Studio, then sever thousand others have also.
The community around MonoDevelop is just not as big as Visual Studio’s and lacks the zeal required to overcome the number difference.
Now, with the actual developing in these IDE’s. One of the important things I have learned while working with MonoDevelop is that it is an animal that does not hibernate or sleep. Should you try to make it do either, it will get very angry and will commit suicide dragging other things such as gedit down with it. I have no idea how this happens, just that I should never, ever use the laptop keyboard that has sleep as an option key next to escape.
For the most part, both IDEs work great. They both support intellisense, templetes, and anything else you would expect from a modern IDE. I did have an issue with MonoDevelops refractor. It would either not work or it would work too well and refractor things it has no reason to. MonoDevelop has the added bonus of including a built in SVN tool which works great for simple commit and updates.
On the Visual Studio side, I miss the ability to right-click on a program with a Main method and run it; having to go into project properities is an annoyance. Also the inability to save command line arguments for programs is causing a lot more more mouse clicks and keyboard strokes then would be prefered. Probably my biggest issue with Visual Studio is that it runs on windows and therefore it runs console applications in a terminal that doesn’t allow text selection.
MonoDevelop is a great IDE, but has enough rough spots to warrant its use in industry to be limited. Visual Studios has everything that is needed to be productive and more on top of that, not to mention enough people using it to get help when needed.
After 5 weeks, the core work on the Download Statistics project is coming to an end. It has been a fun project to work on with its many ups and downs. It is also refreshing to work on something that has real world value. Over these past 5 weeks, I have been tasked with creating a suite of applications that will retrieve download logs, parse them, and display them in a MindTouch installation. Aside from some optimization and tweaking, these goals have all been met. It is almost time for my suite to be graduated to release candidate.
Here’s a screen cap of what the Dekiscript front end will dynamically generate.
While working on this project, I have come to realize several things:
- If you can do it with a system library, there is likely a mindtouch.dream library that does it better.
- Libraries are made to be used, it is not academic dishonesty to use open source libraries from the Internet in projects.
- If you can’t find your problem/idea on Google, it is not because it doesn’t exist, it is because you are not specifying it correctly.
- It pays to structure the internal folders of the project ahead of time, pays roughly 6 hours of wages to be exact.
There are many more things that I have learned since my first days here, but the above are very directly related to the project that I have been working on. One of the hardest things for me to learn is that the methods inside System are very often time not the methods that I want to use. Coming from Java and structured school assignments, it is also hard to get over the fact that everything you every need isn’t already in the default libraries. Also going along with school assignments, curse not being conditioned to use auto completion!
Google is an amazing resource as long as the search terms are correct. No matter how amazing Google is, it can’t make the connection that when somebody searches for “functions’, they actually mean “methods”. Google happens to also always be right, which means that if it can’t be found on Google, then it is user error. Google is also very powerful and has more uses than is productive <http://lifehacker.com/339474/top-10-obscure-google-search-tricks>.
And lastly, structure program correctly in the beginning because an minor error when starting out can lead to several hours of tedious file moving and project properties tweaking down the line. The project was started in Mono Develop using the default solution creator which led to files and folders being stored in a hierarchy very different from the accepted standard. This in itself could be easily fixed, but when submitted to SVN, this folder structure refused to be changed via Mono Develop’s SVN interface. In the end, it took several hours and Arne’s help to just recreate the structure correctly.
Aside from these, the project went smoothly. Most of the deadlines were met with a bit of task juggling and a product is close to completion.
Post to come:
- Intern’s Advice to Future UCSD Lackeys
- Mono Develop vs Visual Studios
Good morning everybody! I am Ricky, a freshly recruited intern here at MindTouch, Inc. I will be working with the other engineers here to help make MindTouch even better then it already is now. A quick bit about myself; I am a student at UCSD, the only UC that has an inorganic mascot, studying Computational Cognitive Science and Computer Science. While working at MindTouch, I will be under the tutelage of Guerric, who has already tasked me with a fun project to help slowly introduce me to the wonders associated with being a programmer.
My first project has been tentatively named “Download Statistics”. The goal of this project is to create a system that is suited for creating various download metrics in order to make better informed product decisions. The two major sources of information will be from Apache logs generated from repository downloads and a proxy for web downloads. This all gets processed and stored inside a database. This database will then be accessed through use of Dekiscript allowing pretty presentation of the data in meaningful ways such as real time tracking of unique downloads.
An interesting things about this project is that I will be using MonoDevelop as my IDE. So far it has been a fruitful experience and will hopefully lead to more of its use at the company.
And an interesting thing about my experience in the company, everybody uses laptops! It is so weird to see everybody working on laptops, especially 12.1 to 13.3 inch ones! And going along with laptops, the one that I brought to work, an old Dell Inspirion 1410, outright froze on the first day from the strain. Maybe it’s time to get an indestructible Thinkpad T500.