Hey everyone, I’m Mark Anderson, and I’m the new Senate CIO. Since most of the WTG has graduated, we’re entering a rebuilding season. As soon as school starts, we’ll be setting up a regular meeting time, and begin to set out projects for the year. If you’re interested in participating or have any ideas, contact us.
And, watch this space. I’ll be updating on a regular basis.
I recently got back from a conference talking about open source software and walked away with the satisfaction that the Concerto of yesterday was a really successfully project by most measures but the depressing reality that Concerto 2 isn’t so fortunate right now. I want the Concerto of tomorrow to be more successful, but I can’t do it alone. I also can’t do it with just “the heavyweights” of Concerto 1′s development. Many core developers now have jobs that, believe it or not, make it hard for them to cram into our office space and work on features until 2-4am. In theory I’ll have a full-time job soon, which is why I’m trying to get this off the ground sooner rather than later.
Most of what I’m going to present is centered around this philosophy that our development, in addition to our releases, need to be open.
If you’re interested in getting on board with Concerto as we set sail again I encourage you to follow the contributors guide here (https://github.com/wtg/concerto/wiki/Getting-Involved) to sign up for the mailing list and create an account on lighthouse. Discussion will continue on the new mailing list very soon regarding some of the more brick and mortar contributions that you can start making today.
Welcome aboard.
Everyone love Concerto’s ability to easily enable content creators to get their message out there via graphical slides and text, a few brave souls have even used the dynamic content support to redistribute RSS feeds and other external data sources to their screens. What’s missing from this picture? Video. Video is probably on the top 10 missing features list, something I never thought any significant number of people would want in their digital signage system…. good thing I try to stay away of judging what people want or not when we’re developing features.
That said, you’ve asked and I decided to deliver. I really hate answering questions without providing a satisfactory answer and saying “we’ll look into video for Concerto 2″ might have been OK to write it off the first two times… but by the fourth and fifth time I really wanted to do something about it. Luckily I had the opportunity to solve a problem for my IT for the Arts and Performance class at RPI, and this seemed like a great fit.
If you’re not interested in hearing all the details, I’ll skip to the punch: I’ve developed video support for Concerto 1.9.x, and I’m optimistic it will be merged into the trunk and released over the summer.
Onto the details….
Since Concerto is open source, my options to implement this were a little bit limited. We’re not comfortable (I don’t know if its legal or not) distributing Flash Player on our Live CD images, and I really didn’t want to cheat and use a system that couldn’t be cleanly distributed to everyone. Luckily, most modern browsers (Firefox, Chrome, Safari) support the HTML 5 <video> element, providing a plugin-free way to play video content. By the wonder of HTML “standards”, massaging a <video> element into the graphics field enabled a screen to cycle and play back video clips just like any other piece of content.
Technically speaking, “massage” includes a several fixes to the screen JavaScript to be less destructive when it resizes non-text based elements and a lot of work making the <video> element work and play for as many people as possible in as many places as possible (i.e. admin panel & API).
When you upload a video, a python script is called in the background to start encoding the video to H264 (Safari, Chrome) and OGG Theora (Firefox, Chrome). Regardless of who you are, the video sits UNAPPROVED while the processing goes on. Its up to a moderator, to manually approve the video when processing is complete. In case you didn’t get that the video will not be approved on any feeds, even those which you moderate (I completely forgot this during my demo, resulting in 4 minutes of awkward stalling). To keep you company, a “processing” graphic is shown to let you know that the python script (and ffmpeg) are doing their best to convert the video. The longer the video, the longer it will probably take to convert.
Hocus pocus, after the video is encoded the “processing” graphic will go away and you can preview the video everywhere in the admin panel. Internet Explorer users be warned: You’ll be shown the video in a Flash Player which may or may not automatically figure out the aspect ratio. If you are concerned, try another browser.
The python script includes some very basic ffmpeg commands to encode the video, if you’d rather use a different set of options (bitrate, quality, etc) or another command line tool (HandBrake?) to encode your video feel free to edit things around… the only important thing is the output file location.
If all goes well, which I don’t see why it shouldn’t, this code will be committed to the trunk in a week or two. Since the screen JavaScript was changed, we do have to be extra careful that no memory leaks or bugs were introduced that could break the content-cycling on the screens or cause FireFox to crash. Testing this usually involves running a development screen for a few days to make sure nothing crashes…
I can’t promise I’ll implement another moderately-desired Concerto feature in the next month or two, but I’d love to hear what we should be working on for Concerto 2. If you’ve got any ideas, I’m all ears.
I’d like to thank the efforts of Brian Michalski, Zach Rowe, and Kenley Cheung. This morning, we pushed out a huge set of much-needed updates to our document manager software. It’s much better now.
Included in these changes are the following:
We still have a logo set brewing for the Flagship suite of products, and we still have enhancements to make, especially to Flagship’s Quick Search. But for now, these changes should make Flagship an even more compelling docs package than before!
UPDATE 3/21/2010 9:30pm: Looks like I’ve managed to break things early. We might be back online before the scheduled upgrade, but I don’t know for sure.
UPDATE 3/21/2010 10:11pm: …and we’re back. Everything should stay online until around 9:45 tomorrow morning.
UPDATE 3/22/2010 12:00pm: Maintenance complete. It took only about an hour to bring the new server online, the longest part of the entire process was having to run back to the Student Union to get the right sized screws. Shuttle Tracking should be in for some smooth sailing.
Shuttle Tracking will be down for maintenance Monday, 3/22/2010, starting at 9:45AM. If all goes well, the service should resume operation before noon. During this downtime we’ll be shutting down the old shuttle tracking server and bringing the new one online. Since we have limited rack space available, the old server has to be shut down and physically removed before we can bring the new one online.
We’ve seen huge increases in traffic to the site as more students are living further away from campus (presumably looking to take a shuttle). The new shuttle server was purchased after meeting with Claude Rounds, the VP for Administration at RPI who recognized the need to support our program and continue to provide the best shuttle tracking experience possible. We’re also going to be looking into developing estimated arrival signs for some shuttle stops, a mobile interface, and exploring a technological solution to the shuttle-clumping problem.
Technically speaking, you’ve been experiencing the new server for weeks. After getting the new server setup, it was brought online in the Student Union and the current shuttle tracking server was adjusted to proxy all of its requests along to the new server. As a result, we were able to get a lot of the speed increases out of the new server while we waited to get it installed in a more permanent home. Tomorrow we’ll be able to complete the update and remove the old server from the shuttle tracking stack, it will probably be re-purposed as a development server or staging area for future upgrades.
If things are going poorly, there’s a chance I’ll be tweeting about it (@bamnet) but I don’t foresee us hitting too many bumps in the road.
We just began work on Flagship Base, a new Flagship product that is meant to cleanly and simply allow users to create managed knowledge bases for application support. It’s going to be a really exciting new WTG property that will play nicely with many other applications, such as Concerto 2 and the other Flagship applications that have either launched or are in development, such as Flagship Docs 2 and Flagship Tasks. It will use a lot of common components from past and present projects, including Split-Views from Concerto 2 and the amazing new Quick Search in Flagship Docs 2 (try it out at the RPI installation).
We’ll be talking more about Flagship Base and the future of Flagship soon. Stay tuned!
Concerto 2 looms ever closer, yet it’s still on the horizon. We’re beginning to ramp up development on base Concerto 2 features and functionality. First, we’ll be filling in all of the functionality that Concerto Version 1 had, including basic feed and content management, screens, and browsing. In many cases, and because we’re rebuilding the core of Concerto in Ruby on Rails, the architecture will be vastly streamlined and incorporate a whole heap of feedback that we have received over the years based on Concerto Version 1. For example, the Concerto Wall will be directly integrated into the browsing interfaces as a new Wall View (the counterpart to our more traditional Detail View). Think of this Concerto 2 core as a leaner, meaner rebuild of everything that made Version 1 great.
From that point, we’re going to branch out into new functionality. The Concerto 2 architecture is designed to focus a lot of the additional functionality beyond core functions into plugins that can be “added on” to the core software. These plugins will be for hardware and power management, dynamic content, and other things. We hope to encourage the development of additional plugins to further expand the capabilities of Concerto 2 in the future.
This is the start to our Concerto 2 roadmap. We are organizing the roadmap into milestones (MS) based on types of functionality. This roadmap begins this week. We hope that each milestone will take no more than a couple weeks.
MS1: Feed Management
MS2: Browse Content
MS3: Screen Backend
MS4: Authentication
In addition, there are other parts of Concerto 2 that we’ll put on the big board right now without any great sense of organization. These will enter into our roadmap as additional milestones once the four above are completed. In no particular order, they are:
As we get deeper into development, we’ll be talking about other fun things, which may include things like video and Flash support. Please continue to give us comments at our forum and via email at concerto@union.rpi.edu.
Concerto 2 development is booming away, with Brian Michalski scaffolding out a lot of the views in Ruby on Rails 3 and me working on fleshing out a lot of the foundational GUI designs. We launched Concerto Wall in Update 1.9 last year. I created the Wall as a new user interface implement to better display lots of graphical messages to the user in an attractive grid view, much like the thumbnail views seen in Windows 7, Mac OS X, and Ubuntu Linux. However, because it was added late in the development of Version 1, the Wall never became deeply integrated into Concerto’s UI.
For Concerto 2, I’ve wanted to offer the Wall as a method for displaying any kind of serialized content, such as graphical flyers and videos (more on this later). Granted, it should be an option, not a forced interface. A more conventional Detail View should also be an option, and the user should be able to toggle between the various views, much like with an OS file browser.
My initial mock-ups separated the content feeds (essentially the “categories”) into a left sidebar with clickable listings. The right panel would then show the contents of the particular category that has been selected. What isn’t in the initial mockup is the selector for the Detail View. The Wall View that is shown is very different from what we had in Concerto 1, which was a sortable, expanding and collapsing table. That view is probably a lot more like what the Detail View will be for Version 2.
My goal with the Concerto 2 UI mock-ups was to show that we can carry the more visual way of presenting information about screens to the entire interface. Users should be able to quickly zoom into content and take a look at it. We found in our interactions with users with Concerto 1 that people often preferred to visually scan the interface for important information and alerts; it was just more natural and intuitive than peering through a details-based view, though certainly the latter is important to keep in order to quickly find important, less common details about Concerto content (duration, date ranges, the person who submitted the message, and so forth).
As I thought about the Concerto 2 sidebar design, I realized that many elements of our core application – browsing screens, looking at content, checking user groups, and so forth, can be organized into the same kind of two-column UI. Doing so would create important consistency across the entire application. With Concerto 1, many of our different functions used different interfaces that we made in the rush to move the product out. With Concerto 2, it’s important to refocus and maintain consistency, as that helps users navigate through the application.
I sketched out on paper how I feel the Split-View Interface, as I call it, should function. Selectable categories would be listed on the left in the sidebar, and once one is clicked, it would then show its contents on the right. The categories could be feed names, locations, user groups – whatever. However, in the case of feeds, we are going to allow nested feed hierarchies for Concerto 2. These parent-child relationships will allow operators to create much more specific sub-categories of content types. For example, Japanese Culture could be a sub-feed of Multicultural. Concerts naturally belong to Entertainment. Because of this nesting nature, the right panel of the Split-View would be grouped based on the sub-categories, if any, that are within the selected category. From that point, if a user clicks on the group header in the right panel, the Split-View would change both its left and right panels to show the hierarchy using that specific category as the root. There would be a back button on the left immediately above the category tree, to allow the user to return to the previous view. The right panel groupings were actually inspired by Apple’s iPhoto user interface.
This interface is still untested with our actual users, so the next step is to actually build it. We will be working on leveraging Rails’ partials to create the Split-View Interface and make it extremely modular. My hope is that we’ll be able to specify the parent of whatever hierarchy exists (such as a feed, user group, or screen) and make it render the full interface based on that information and on the relationships that it sniffs out between objects in the hierarchy.
Oh, and one other thing: we’ll soon be talking about a more formal roadmap for Concerto 2. What I can tell you is that we’re prepping it for “the spring.” Stay tuned!
Concerto 2 represents an extraordinary opportunity to build upon the past successes we have from Version 1 of the software suite with cleaner, more consistent designs and code. We’re retooling the design from ground level to be faster, more user-friendly, and more flexible for our long-term ambitions with Version 2. Some of the most overt changes will be right there in the main menu of the web application once you log in.
Concerto 1 had a very conventional tabs system for allowing people to access all of the different parts of the software that they wished to use. This architecture worked well enough for our purpose, yet it suffered from a few key deficiencies:
With these weaknesses in mind, I set out to design the next generation of Concerto’s menu architecture. Even from the start, I wanted to design the UI for Concerto 2 to incorporate the strengths of our visual screens interface in Version 1. This page allows users to quickly see a visual indicator for the status of each of the screens active in the Concerto network. For example, if the screen is asleep, it was represented by an icon with little “Z”‘s, so as to appear to be sleeping. This kind of interface element is a favorite for our users, so it made sense to build upon it.
My first menu design was very unconventional and minimalistic. The idea was that the user could simply visit the Concerto 2 web application and see visual lists of screens and content without having to log in. The top button would pull down a login form to facilitate the user authentication if desired or necessary for certain functions (such as uploading new content). However, I soon realized that such a barebones menu design would not suffice for the plugin architecture that we were designing. How could I expect to fit specialized controls into this unconventional design?
This semester, with the Concerto 2 release looming on the horizon, I set out to actually implement the menu system, and that involved a redesign. My new design was more straightforward, yet I included a grouping in the main menu items. The user login, which again will not be necessary to browse content or do most other things, is now in the top left. This design, I feel, saves space while leaving plenty of room for plugin-centric controls. I also included a search area in the top right corner, which might reveal a search box when clicked (much like Apple’s awesome documentation interface, as seen here).
Next was to go through the actual process of implementing the menu interface. I created a Photoshop mock-up with all of the graphical elements, and then cut it up and built it using HTML and CSS. I’m very happy with the results. You can check the new menu system out in early form in our git repository for Concerto 2.
Here at the WTG, we love to be on the bleeding edge. Which is why we installed the Rails 3.0.0.beta gem on our development server. But of course, Rails 3 has a way to go, and we might not be upgrading our production apps for a while. So in the meantime, we’re working in both worlds.
A problem comes up if we try to put together a new Rails 2 app. In order to build the app, you need to run the executable for Rails 2, but when we upgraded to Rails 3, running “rails” from the command line results in a shiny Rails 3 app, with no path to execute the older versions easily.
Rubygems provides a nice syntax for dealing with gem versions, in most cases. You can specify a particular version of the gem that you want to use on the commandline as the first argument to the command and in underscores:
rails _2.3.5_ myapp
But between Rails 2 and Rails 3, the rails bin moved from the Rails gem to the Railties gem (Railties is a dependency of Rails). So the above syntax doesn’t work anymore.
Fortunately, the executable that you run when typing /usr/bin/rails is a short ruby script that delegates all the functionality to some scripts located within the gem (see the source here). All we have to do is modify that file to be a little more intelligent. I’m not accounting for Rails 1, just identifying calls requests that look like they want the Rails 2 executable.
Just replace your /usr/bin/rails (or wherever you keep your executable) with the following:
#!/usr/bin/ruby1.8 # # This file was generated by RubyGems, then edited for Rails 2 # backwards compatibility. # # The application 'railties' is installed as part of a gem, and # this file is here to facilitate running it. # require 'rubygems' version = ">= 0" rails_gem = "railties" if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then version = $1 ARGV.shift end if version =~ /^2.*$/ rails_gem = "rails" end gem rails_gem, version load Gem.bin_path(rails_gem, 'rails', version)
Now you should get:
$ rails _2.3.5_ --version # => Rails 2.3.5 $ rails --version # => Rails 3.0.0.beta
Now, for convenience, we might just want to have a Rails 2 executable. Put the following /usr/bin/rails2, and set it to be globally executable.
#!/usr/bin/ruby1.8 # # This file should be run to run the 'rails' command from the # rails 2 gem. # See http://webtech.union.rpi.edu/blog/2010/02/24/rails-2-and-rails-3/ require 'rubygems' version = "< 3.0.0.beta" if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then version = $1 ARGV.shift end gem 'rails', version load Gem.bin_path('rails', 'rails', version)
Just call “rails2″ to use the latest version of rails 2 available, or specify a particular rails 2 version. You can use this without having the above modification to ‘rails’ or have them both for maximum convenience.
$ rails2 --version # => Rails 2.3.5 $ rails2 _2.3.4_ --version # => Rails 2.3.4 # Works, but same effect as runnning rails 2.3.4 with the 'rails' script we wrote above. $ rails2 _3.0.0.beta_ --version # Doesn't work. Just use the 'rails' command.
This should all continue to remain working as future rails 3 gems come out, as long as the above files don’t get overwritten (you may have to re-paste the code if a future gem overwrites that, so keep this link around). It would be really nice to see this sort of functionality handled automatically. In the meantime, though, the above should keep you running comfortably.
All the above code is available here: http://gist.github.com/313946, and the originally generated /usr/bin/rails for Rails 3 is here. Comments welcome.