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?
Seeing how Young Hahn, David Rothstein, Paul Lovvik, Charlie Gordon, Daniel F. Kudwien, myself and others work on parts of the Drupal 7 user experience implementation already, it is getting harder to apply all the patches, keep up with their development and get them integrated to work together with various efforts.
At Acquia, among other Drupal 7 UX improvements, we've been working making the overlays work as designed by Mark Boulton and Leisa Reichelt. The plan includes a header with two levels of fixed items, which all invoke overlays (almost full window popups), showing above the current page. Instead of reinventing the wheel, we started working towards porting the existing Popups module to Drupal 7 and implementing the Drupal 7 overlay looks via a skin, so we can leverage the existing work, testing and wisdom from the module.
Due to how hard JS is to debug still with Firebug, we faced some issues, but given that we are over those, we have the basic overlay looks ready and facing some other engineering problems which are pretty much standard with how the Popups module works. For integration purposes (and because our proof of concept version of the header did not look as good), we worked with Young Hahn's header patch. You can find my modifications to that to work with overlays on the issue. While Young's patch does not yet map to the D7UX plan to have a fixed set of top level items and a fixed set of lower level items, redefining the D7 admin information architecture, for working out the overlay, it is pretty good as it is now.
Since we were working on (a) porting Popups module to Drupal 7, (b) create a d7ux skin for it, (c) a header which we did not use in this experiment, and Young Hahn was working on a header which needs a patch and images added, I've decided to pull together a quick Drupal package for your testing pleasure. The distribution includes a D7UX install profile which should be used so that the proper modules are set up. It also includes the latest header patch from Young's issue (which has my popups class modifications) and the images and sprite from there. The ported Popups module and the D7UX skin for it is also included.
While I am searching for the best ways to collaborate on the overlay (and possibly also on the header), so we don't need to work back and forth in issue queues, possibly stepping on each other's toes, I am also sharing the D7UX Popups module theme as a separate package, so those fond of applying patches and adding up images from different sources can keep up with development.
There are some pretty significant known issues with the overlay/popups. The biggest one being that since the overlay page is loaded into the same DOM tree (same HTML document) as the rest of the page, ID collissions can easily apply. If you load up a node edit form on a page with a node edit form, #node-edit will appear twice. Behaviours rightly assume that an HTML ID will ever appear once, so they do not expect this situation. This breaks some behaviors. Also, since Popups modules opens new popups on clicking on new links without closing the previous ones, this can also happen if you open two node forms in the popup in a page view. There are also smaller styling problems (eg. overlays on lower layers move up a few pixels when new popups are opened), but we should focus on the significant issues first.
I am looking at breaking down the Popups module (again) to core patches so its parts can be included in core. That would assume that the basic working of it (loading up new HTML-particles into the same HTML document) can be made work without major issues. The great maintainer of Popups module, Tao Starbow worked on quite a few core patches, but unfortunately those got the fate of the overdebated. The issues were split up, then some of the individual pieces were discussed to be over-generalized and in other areas, the scope of Popups in core was narrowed considerably to some confirm forms. No doubt Tao got burnt out from there.
That was way before Mark and Leisa suggested using the overlay technique for the Drupal 7 administration UI. I hope we can revive and refocus some of the issues and get this effort going faster, so we can focus on usability of the actual admin screens showing up in the overlays. Rendering API, JS and CSS wizards welcome! Look for my upcoming blog post on a plan to get this into core!
My previous blog post entitled On a mission to improve page regions in Drupal 7 outlined how special casing things like custom help settings, the mission statement and footer message make understanding and using Drupal harder and general assumptions not being applicable to set text formats or visibility on such items. Having the somewhat special content region was also another example.
