Just wanted to pass along a little trick that I use when writing software. About half of our 600 monitors are still 1024x768. We don't replace monitors until they are dead as good custodians of taxpayer dollars, and LCD panels are lasting many years. Usually IT developers have wide screens and some of them have dual monitors. It's easy to forget about the rest of our users, and suddenly software is developed that doesn't fit on their screens. Nothing worse than having to re-engineer a beautiful UI after finding this out during beta testing.
So what I always do is use my handy wallpaper that has a black box drawn at 1024x768 for testing screens.
Thursday, May 19, 2011
We Have Print Data
After some short meetings with our Director and other staff, there seemed to be some excitement about analyzing our printing data. They gave me a list of some additional functionality and I had fun learning how to use some new widgets with Python/Glade and how to retrieve data from sqlite. I don't get the chance to write software very much anymore, and I still find it enjoyable after all of these years.
Here is the shot of the UI, simple and easy to use. The users select the data range, the departments and then the various functions they wish to query. The information is returned in three tabs on the right side which appear as "Department", "Printers" and "Users". One of the requested features was the ability to get the data as it appears in the Tree into OpenOffice Calc. The sqlite query is looping to fill the tree, and it was very simple to just dump the data concurrently out to a perl library which allows you to generate an identical .ods file. When the Tree displays, the file is finished and ready for use. I added an area labeled 'Files' which contains the spreadsheets. When clicked, the buttons use the normal MIME popups that we use on the rest of the desktop. The perl library does not generate the thumbnail file that normally appears in an .ods file, so the preview window comes up blank.
In the shot below, I selected OpenOffice - Calc opens the .ods file and will allow them to tinker with the numbers or copy and paste into other applications as needed. It took a bit of Googling to find the right technique to get the numbers over as integers and not as strings. But it's all working.
The primary UI gives them SQL SUMs of the various data, and I knew that people would be shocked at the number. So if you double-click on any of the Tree rows, it opens a child window which performs the same SQL statement except showing the detail records. It's very interesting to be able to see all print jobs by department, printer and user in chronological order. You can really get a better understand of how people are using/abusing the software.
I have a bit of work to do yet to merge in the log files coming over from the MS Windows spoolers which are in a different format. At that point management can review the data and consider ways to reduce costs with the use of other technologies such as portrait monitors, policies, training and tablets.
Here is the shot of the UI, simple and easy to use. The users select the data range, the departments and then the various functions they wish to query. The information is returned in three tabs on the right side which appear as "Department", "Printers" and "Users". One of the requested features was the ability to get the data as it appears in the Tree into OpenOffice Calc. The sqlite query is looping to fill the tree, and it was very simple to just dump the data concurrently out to a perl library which allows you to generate an identical .ods file. When the Tree displays, the file is finished and ready for use. I added an area labeled 'Files' which contains the spreadsheets. When clicked, the buttons use the normal MIME popups that we use on the rest of the desktop. The perl library does not generate the thumbnail file that normally appears in an .ods file, so the preview window comes up blank.
In the shot below, I selected OpenOffice - Calc opens the .ods file and will allow them to tinker with the numbers or copy and paste into other applications as needed. It took a bit of Googling to find the right technique to get the numbers over as integers and not as strings. But it's all working.
The primary UI gives them SQL SUMs of the various data, and I knew that people would be shocked at the number. So if you double-click on any of the Tree rows, it opens a child window which performs the same SQL statement except showing the detail records. It's very interesting to be able to see all print jobs by department, printer and user in chronological order. You can really get a better understand of how people are using/abusing the software.
I have a bit of work to do yet to merge in the log files coming over from the MS Windows spoolers which are in a different format. At that point management can review the data and consider ways to reduce costs with the use of other technologies such as portrait monitors, policies, training and tablets.
Wednesday, May 11, 2011
Paper & Printer Usage Under Review
As part of the GNOME desktop upgrade, a project has been initiated that is near and dear to my heart -- printing. There is a strong culture in many people to fight computerization and continue to work with 10 or 20 year old techniques. The amount of paper and ink used is tremendous and our printing costs are finally coming to light.
CUPs dumps flat files into /var/log/cups/page_log which contains lots of useful information, but is in no way in a format that can be researched. This is especially true when you have multiple servers and operating systems. We have always known that printers are heavily used, because they are a big draw on IT support. However, we have never been able to prove an exact dollar amount nor provide any specifics about poor techniques being used around the City. So I wrote some quick ksh scripts that scan through the page_log each night at midnight and dump the information into a sqlite database. This is yielding very interesting information.
I have done some SQL statements by hand to begin to look at the data, but obviously this isn't going to be the way that the IT Director or analysts will work. So I am writing a quick Glade/Python screen for running the various searches and the current shot is below. This won't be used by end users and won't get much more bling & art. It will serve the purpose of allowing our staff to select a date range, select departments and then include/exclude various desktop functions. The ink coverage is estimated per print job and we will be able punch in the per page cost for HP printers and it will give an estimated cost of the range selected. Initial estimates are that this cost might be north of 150K a year. :\
If we can use the new desktop, portrait LCD monitors and iPads to change peoples work habits, I believe we can increase efficiencies and reduce costs.
CUPs dumps flat files into /var/log/cups/page_log which contains lots of useful information, but is in no way in a format that can be researched. This is especially true when you have multiple servers and operating systems. We have always known that printers are heavily used, because they are a big draw on IT support. However, we have never been able to prove an exact dollar amount nor provide any specifics about poor techniques being used around the City. So I wrote some quick ksh scripts that scan through the page_log each night at midnight and dump the information into a sqlite database. This is yielding very interesting information.
I have done some SQL statements by hand to begin to look at the data, but obviously this isn't going to be the way that the IT Director or analysts will work. So I am writing a quick Glade/Python screen for running the various searches and the current shot is below. This won't be used by end users and won't get much more bling & art. It will serve the purpose of allowing our staff to select a date range, select departments and then include/exclude various desktop functions. The ink coverage is estimated per print job and we will be able punch in the per page cost for HP printers and it will give an estimated cost of the range selected. Initial estimates are that this cost might be north of 150K a year. :\
If we can use the new desktop, portrait LCD monitors and iPads to change peoples work habits, I believe we can increase efficiencies and reduce costs.
Wednesday, May 04, 2011
A Good Detour Through Lake Worth Florida
The week has been productive. One smaller project that I completed was resyncing avant-window-navigator to the latest versions and deploying this on our Beta desktop. This has a fix in that allows the shinyswitcher to work with VNC and NX connections. I'll be testing that fully this afternoon. This was the last patch required to allow iPads to log into the City and get a fully functional desktop. Cool stuff.
The other project was initiated with a conference call to our IT friends at Lake Worth, Florida. They are exploring ways to implement thin clients, Linux and open source software packages. We offered to send them a copy of our customized thin client build to assist in this process. A customized build has a serious flaw: It's a customized build. :) It was designed for us, and our networking designs were hooked into the scripts which have matured and changed through the years. We have a long term goal of redoing our IP scheme, so making the thin client build a bit more modularized was on our radar anyway. I grabbed some post it notes and went through the code and made a list of all server connections and features that other organizations might want to disable and then built some new UI screens that appear on first boot. The new design makes IP changes a snap, and allows for additional government agencies to piggyback off the project if they so desire. A few hours of design, coding and testing and it's working. There are still some additional areas that need work, but enough is done that we can now ship them a copy of the build and it will work on their network. The UI could probably be better, but it only displays for 30 seconds the first time a thin client is configured and never is seen again. I got feedback from our support division and these screens allow them to touch and update a thin client faster than ever.
On first boot (factory settings), splash page is generic. This provides a visual cue that no settings are configured and the build is currently generic.
The build detects no settings and comes up to a configuration screen (glade/python) that requests that you pick the desired City. (( If you are a Government agency and thinking about HP 5745 thin clients, email me and let's chat about adding you to the build ))
The Site Settings tab has all of the options and IP addresses of servers.
Select the monitor resolution. We hard code the values into xorg.conf to ensure a consistent user experience.
How many monitors does the thin client have?
Does the monitor physically rotate to landscape and portrait? If the monitor doesn't turn, why even allow them to do so?
What is the function of the thin client? Some are are used for desktops, and others are used for Kiosks (human resources, cyber cafe).
After saving the settings, the thin client is now configured for City of Largo.
And users in Lake Worth will get all of their customized artwork.
It's always exciting to hear about other agencies that are exploring ways to save money and as mentioned, these changes improved the quality of code and functionality at our site as well.
The other project was initiated with a conference call to our IT friends at Lake Worth, Florida. They are exploring ways to implement thin clients, Linux and open source software packages. We offered to send them a copy of our customized thin client build to assist in this process. A customized build has a serious flaw: It's a customized build. :) It was designed for us, and our networking designs were hooked into the scripts which have matured and changed through the years. We have a long term goal of redoing our IP scheme, so making the thin client build a bit more modularized was on our radar anyway. I grabbed some post it notes and went through the code and made a list of all server connections and features that other organizations might want to disable and then built some new UI screens that appear on first boot. The new design makes IP changes a snap, and allows for additional government agencies to piggyback off the project if they so desire. A few hours of design, coding and testing and it's working. There are still some additional areas that need work, but enough is done that we can now ship them a copy of the build and it will work on their network. The UI could probably be better, but it only displays for 30 seconds the first time a thin client is configured and never is seen again. I got feedback from our support division and these screens allow them to touch and update a thin client faster than ever.
On first boot (factory settings), splash page is generic. This provides a visual cue that no settings are configured and the build is currently generic.
The build detects no settings and comes up to a configuration screen (glade/python) that requests that you pick the desired City. (( If you are a Government agency and thinking about HP 5745 thin clients, email me and let's chat about adding you to the build ))
The Site Settings tab has all of the options and IP addresses of servers.
Select the monitor resolution. We hard code the values into xorg.conf to ensure a consistent user experience.
How many monitors does the thin client have?
Does the monitor physically rotate to landscape and portrait? If the monitor doesn't turn, why even allow them to do so?
What is the function of the thin client? Some are are used for desktops, and others are used for Kiosks (human resources, cyber cafe).
After saving the settings, the thin client is now configured for City of Largo.
And users in Lake Worth will get all of their customized artwork.
It's always exciting to hear about other agencies that are exploring ways to save money and as mentioned, these changes improved the quality of code and functionality at our site as well.
Subscribe to:
Posts (Atom)