Did you ever wonder what those white boxes in the layout editor part of the Ocularis client is for?
Ocularis has some hidden “gems”; One is the layout command called “box”, swing by http://sdk.onssi.com and find the docs for LoadLayoutFromString. Somewhere in there, you will find a description of the experimental feature called “box:”
string layout =
vport: 0, 0.000, 0.000, 0.500, 0.500
vport: 1, 0.500, 0.000, 1.000, 0.500
vport: 2, 0.000, 0.500, 0.500, 1.000
vport: 3, 0.500, 0.500, 1.000, 1.000
salvo: 0,0,0,NetDVMS://UserName:Password@127.0.0.1:80/[Axis 223M] Camera 1
salvo: 1,0,0,NetDVMS://UserName:Password@127.0.0.1:80/[Axis 214] Camera 1
salvo: 2,0,0,NetDVMS://UserName:Password@127.0.0.1:80/[Axis 215] Camera 1
salvo: 3,0,0,NetDVMS://UserName:Password@127.0.0.1:80/[Axis 231] Camera 1
You need 4 viewports and a salvo for each ( the term salvo is prob. misleading, but you get the idea ), and the end result is pretty cool. This could be used at trade-shows or for in-store displays I believe.
Bonus Info from the presentation I did at Kontorlokaler.dk on “Innovation”.
Paradox of Choice
Joel on Software
The guy I shamelessly copied
ZeFranks Brain-Crack Rant
TED search for the authors above
The next frontier in Video Surveillance Software is USABILITY!!
I hope that this is a lasting trend; I think that it is evident that the Ocularis client has a lot of focus on the user experience, partially because we all enjoy a good UI ourselves, but also because it makes financial sense to make things SIMPLE for the users, for us (fewer support calls) and for the end-user (less training, happier employees, fewer unproductive hours).
Users finally starting to make demands
There has been a tendency to push product rather than end users pulling (requesting a particular solution). A lot of players have the same, middle of the road, design; A tree with some devices on the left and a matrix on the right. Almost all systems use this model, so the differentiation of the products boils down to frames per second, and number of supported camera vendors and finally a “feature fest”.
Not so simple
A simple UI does not mean that it is easy to implement or, perhaps more importantly, it is very hard to agree on a usable design in the development process. It really requires a director who is – in lack of a better term – an “arrogant a-hole”.
Frequently, in large teams, you will always find a number of people who believes that THEIR feature is absolutely critical for the application. This is where the arrogance is needed; sometimes the director must state – “this is an awful idea – idea discarded!”, and then prepare to be on the receiving end of a barrage of complaints and insults about his/her intelligence.
Michelangelo is supposed to have said that creating the statue of David was easy; He simply removed all the “non-David” from the block of marble. In the design of an application we can “do anything”, so the trick is to decide what NOT to do.
Naturally, just being arrogant is not enough to make a cool product (I wish it was 🙂 )
Bells and Whistles
Creating a remarkable UI is not just about nice gradients and corn-flower blue icons (wink, wink). Google is an example of a rather dull and almost childlike look and feel, but the search engine gives you what you need, when you need it, and usually works as you EXPECT it to work. Once the functionality is in place, THEN you can add bells and whistles.
While nice graphics are secondary to a well functioning UI, they often work as a great motivator for the developers on the team. The idea that the product will look very polished and that the company VALUES aesthetics and good looks sends a signal. Even the most accomplished developer will feel less motivated if the application is “polluted” with garish colors, inconsistent icon design, strange alignments and so on.
Some things are just complicated. An example is the creation of rules in a system. You can eliminate SOME of the complexity by offering a stringent entry system to avoid syntax errors and use of initialized variables etc. (all the problems associated with conventional programming), but the core complexity can never be removed: For all intents and purposes, you are asking the operator to “write a program”. And programs may “work”, yet not do what was expected. After all, any application that you ever ran on a PC was made with this message delivered by the compiler “Compile complete : 0 errors”. This CERTAINLY does not mean the application works as intended.
All in all, the future looks bright for the end-users of surveillance software, or at least – less frustrating.
The layout of a Joomla theme is really more about CSS than anything else. An example is menus – they are usually a bunch of <ul>’s, so to make them look cool you need to know how to change the layout of a <ul> (there are hundreds of CSS tutorials around the net). Other modules are dumped as a <table>; an example could be the newsflash module.
In my setup, the newsflash module is linked to the top position. So to draw the newsflash, the php will contain something like this
<jdoc:include type=”modules” name=”top” />
this will result in this output
<table class="contentpaneopen"> <tr> <td valign="top" >Joomla! 1.5 - 'Experience the Freedom'!....</td> </tr> <tr> <td valign="top" ></td> </tr> </table>
It would seem logical that we just create some CSS for table.contentpaneopen – however – ALL the tables are of this class, and obviously, we need the newsflash to look completely different. The solution is to wrap the top position in a <div>
<div id=”newsflash”><jdoc:include type=”modules” name=”top” /></div>
in the CSS, we can then address the newsflash with this selector
the individual <td>’s are addressed like so
div#newsflash table.contentpaneopen td
This was a pretty brief intro to the Joomla way of thinking. Now go play 🙂