When we talk about video streaming, many people still think of expensive hardware, dedicated uplink capacity and a complicated server side video encoder. However, nowadays video cameras in mobile phones and online streaming services can solve most of the problems for us if we sacrifice a bit on video quality. Drupalcamp Prague was just over this past weekend, and while I was busy presenting two sessions, demoing Acquia Gardens in a third one and speaking of contributing to Drupal in a fourth one, István Palócz was trying to ensure live streaming of the conference will be online.
In practice, the only hardware he used was a Nokia E51 mobile phone. Although it was attached (glued) to a laptop as seen in the picture, the laptop only served as an immediate camera stand. The phone was indeed plugged in almost the whole time to avoid the battery becoming empty, but the streaming was done solely using the phone hardware. Features used to stream were built-in wifi support in the phone, so the streaming can use the event's wifi service to stream the video and the Ustream broadcasting application available for some Nokia and Android phones. Though there is an iPhone app available, that does not support broadcasting.
With a capable phone, wifi and a ustream account, István was able to stream almost the whole event. Outages included when he actually needed to grab lunch so did not arrive back on time for the session and when he got a call. Still, those watching the stream were happy to see the sessions live and enjoy some of the program. I'm not highlighing this streaming technology for its stunning quality (although video quality definitely depends on the camera in the phone). You can check some of István's recordings to see the quality. It's the simplicity of the solution that is amazing. Just plug in your supported phone to a power outlet and stream over wireless. Way to share with the Drupal community!
Things been quite quiet lately here on my personal blog. This does not mean that my days were not action packed though. I was quiet due mainly to being busy with working on all the Drupal 7 usability exceptions and blogging directly on the localize.drupal.org news blog.
The Prague event still has 70 free (as in beer) seats open as of this writing, so it is not late to register! My colleague Robert Douglass will also be there to present sexy search and Acquia. There will be a pretty heavy Hungarian contingent going presenting about Druplash, Services and Amazon EC2 integration plus our Hungarian in honor, Kristof van Tomme presenting knowledge management integration in Open Atrium.
There are plenty reasons to come, so don't miss out!
Mark Boulton created the new Drupal wordmark as part of the Drupal.org redesign efforts. As highlighted by Jeff Traynor of Raincity Studios, the newly relaunched Drupal.com now uses this new wordmark as identification for Drupal and the wordmark is also destined to land on Drupal.org as part of the redesign (implementation unfortunately still underway).
So why not include the wordmark in shipping software as well? A logical step would be to have it on the installation and update (also known as maintenance screens). The patch for using the new Seven administration theme for installation and updates does just that. Because it is only a first approximation of how this should look, I'd love to get help cleaning it up and polishing things like lining up items, correct font sizes and fixing graphics - so we get a really polished experience for people's first Drupal encounter as well.
Finally, the promise of a centralized localization interface for Drupal modules and themes looks to be coming true. I've started work on this project around two years ago under Google Summer of Code sponsorship and was continuing maintenance and improvements ever since. While I was spreading the word on it, not many people signed up to help clean up some possible performance problems, so it did not make into Drupal.org yet.
However, earlier this year I've got reviews from some key people in the infrastructure team, especially Gerhard Killesreiter, who persuaded me that setting this up is more important then it not being perfect yet. Software is evolving matter anyway, and we should improve as we see the problems. So I've started to set up localize.drupal.org. While we work out some of the kinks like single sign-on with drupal.org (one of the promises of the drupal.org redesign which will be delivered here), I thought it would be a good idea to discuss the implications.
Moshe Weitzman recently started the D7CX movement to rally people to get Drupal 7 contributed modules upgraded and released on time for the Drupal 7 release. This would be a great boon to the Drupal 7 release, which shapes up to be a huge improvement over Drupal 6 already. He also suggests a contributed module release manager who can help with (among other things) ensuring that tools are available to help people upgrade.
By now, the Drupal contributed repository grew so big that there are likely multiple solutions to the same problems there. Maybe these solutions solve the tasks with different angles, have slightly different features, but at their core, they aim at solving the same issue. So it is getting harder for site builders to pick the modules they want to use (and drupal.org is planned to offer more tools in helping with the selection). When it comes to core inclusion though, one needs to very clearly define the requirements and meet core goals, such as lean and mean implementation, maintainability and reusability.
With Mark Boulton's and Leisa Reichelt's suggestion to have most of the Drupal administration interface show up in an overlay on top of the public facing webpage, we are again at such technology crossroads. Drupal 6 at least has two contributed modules to implement a similar-looking solution: Popups API and Modal Frame API. Both got their pros when I researched for possible overlay implementations, and frankly, when there are already two modules implemented for the same complex task, why would we start from scratch?
The goals for the core overlay (purposely not called a modal dialog) is to take up most of the window with a dim background on the original page content. The overlay would have a close button on its right side and possibly tabs on top to switch to different subpages (loaded via Ajax or will already be on the same page, but hidden). We don't need the overlay to be moveable or resizable. We don't need to show multiples at once, since it only makes sense to show one. However, the overlay should work well with the header so that when an option is selected, it keeps being active in the header, and the header should work so one can pick another area to work on without first closing the overlay.
This is how the overlay would look:
With different tabs or without tabs but otherwise consistent look elsewhere:
For easier evaluation of how we can meet these goals, I've ported both above mentioned modules to Drupal 7 and implemented Drupal 7 user experience "skins" for them. In the case of Popups module, it was a skin which the module already supports via an internal API, with Modal Frame API, it was an actual glue module which mapped elements marked up for being displayed in the overlay to a style similar to what Mark and Leisa suggests. Neither of them is pixel perfect to what is to be done, but the initial goal was to have D7 versions to evaluate and discuss the implementation internals, so we can fix up styling once we picked either one or a third way.
You can find my Popups module port patch at http://drupal.org/node/466732#comment-1681554 and the Modal Frame API port patch at http://drupal.org/node/491224#comment-1703366 but to make all these easier to test with the D7UX header in progress, all this code is available with the glue modules and custom skins in the D7UX code repository. You can try out both by installing with the d7ux install profile and then either turning on the "Popups API" module or the "D7UX overlay look" module. Make sure to only have one of them enabled at once and let Drupal install their dependencies. Switch between the two implementations by switching between the two modules.
Overlay implemented via popus module:
Overlay implemented via modal frame API module (the close button is not yet themed to look like on the mockups, but think of that as a minor detail):
Reloads originating page (via Ajax or full reload) or runs custom callback
Overrides form submit redirection and closes overlay
We are obviously at crossroads with picking our ways. The Popups module approach already has numerous core patches which were suggested earlier, while Modal Frame API leverages jQuery UI to lessen custom code burden and iframes to avoid colissions in merging HTML documents, which might be more attractive.
What did I miss in my comparison? Did I miss another alternative? What do you think a core solution should look like? jQuery UI to core? Just a targeted custom implementation for our own needs? IFrames or HTML merging? JSON output or overlay specific theming? These are general conceptual questions, so I choose to write a blog post to try and start a conversation instead of using the issue queue, which would be useful for more targeted questions. However, answers to some of the questions infer answers to others. What do you think?
