“Not only is innerHTML bad, it is the root cause of many problems… from browser memory leaks (it destroys/replaces existing elements that may have event handlers attached) to failing completely on iOS’s Mobile Safari. Yes, that‘s right, it just flakes out.”

Read on...

So I made it over the hump of this mobile design week of madness. Below you will find a dark theme with a component skin for the rich:accordion component.

Day 3: About The Design

As you can see with the second page (below), this is not a standard accordion panel type of component. When you touch an option from page one, the accordion expands on a different page and only focuses on that specific panel. Not sure if it could work, but accordion collapse/expand style of components don‘t make a ton of sense to me on limited screen real estate.

So after you go through the menu options and decide on a component, you are taken to the detail/demo screen(below) where you can play around with your component of choice.

Note the small orange page marker dots at the bottom. The user would have the ability to flip through each component in the given section by swiping horizontally.

Day 2 of the RichFaces skinning and we have the first approach for tablet devices. Tablets are a little harder to design for because of a few reasons:

1) Your design sits on the fine line between desktop and mobile. You are designing your app for a max 1024 pixel resolution (in landscape mode) but you must also take advantage of mobile usability (which you will see in page2)

2) Similar to the iPad Mail.app, it‘s almost like you are designing 2 different UI‘s for landscape and portrait modes. For portrait you need more drop down menus, and for landscape you can try to fit everything on one page without the drop downs.

Day 2: About The Design

Notice how, unlike the iphone design from Day 1, I left the browser button overrides within the app itself. Tablet web apps are completely use case driven so this will vary. But since we have so much more real estate, we can play around with standard navigation options that keep the user's attention focused on the app itself.

The second page is what you see after selecting a menu item from page 1 (click to enlarge). Here we have the title bar at the top left with a built in back button which takes the user back to the first screen.

To the right of the title you see the secondary menu represented by rounded rectangles. Next is the main content of the page broken out into content and actionable panels.

And finally you have the big arrows to the right and left. These arrows are “thumb reachable” which is a common usability pattern in portrait mode tablets. It provides an easy page flip access to all of the RichFaces components within the top level category.

The great thing about CSS3 transitions is that you can really make a UI like this scream and flow seamlessly. So you can imagine how tapping an arrow with your thumb will slide in a new component demo and gracefully highlight the secondary menu option at the top.

So this concludes our design for Day 2. As I said earlier, this is more of a use case driven design. WE could spawn a very minimalistic skin and component look and feel from this. However, It would be more to display the power behind RichFaces ajax and templating features as the user moves through the app.

Today marks an important day in the RichFaces project as we continue to head down the mobile web road. Since we have such a great community of users and followers, we want you to be involved with the design process.
So each day this week, I will come up with a new proposed design/theme for RichFaces Mobile and we want to hear your feedback.

I will announce each new design (both for tablet and phone) via twitter with a link back to this article. I will try my best to pick apart each design and describe why I did what I did, and hope you can give me some real world feedback. We want this project to actually make sense and be usable to what you guys are facing in the real world. Without further adieu....

Our first task is to tackle the RichFaces showcase of components. Classifying what is mobile ready and which components may need a little work.

Day 1: About The Design

In this design we have the standard browser “functionality take over” at the top header. The custom back button is essential to mobile web design and must be overridden here – following the pattern of previous designs.

Nothing too different about the standard menu options and detail options (center stage). Following convention here as well. One thing I am adhering too are the usability guidelines set forth by Jakob Nielsen‘s Usability of iPad Apps and Websites

To get the full tab bar at the bottom (and to replicate the native feel) the user must bookmark the application. I think it makes sense for this menu to be contextual to the app and provide other alternate routes.

About TweetStream

The Code...

We used infinispan in both instances, but our @TwitterLocal is a single node caching a direct twitter stream from Twitter4J.

Now that we have our types defined as follows…

We need not only an implementation of each, but also a deciding bean that tells us which type to use.

First, our implementation of each Type implements an interface:

And our implementations have a different usage of the init method. TwitterLocal starts the stream coming from twitter and updates the infinispan cache. TwitterServer starts a method which allows us to start receiving data from the keynote which uses complex event processing and a datagrid with 6–8 nodes.

So now, how do we decide which Type to use? There are a few different ways to do it, but in the case of this being a demo and not a lot of time on my part. I used this approach:

This is all in the source code. Feel free to pull it and make improvements or run it to see it in action. There are many more blog posts to come from this demo, so stay tuned…

Working with portlet technology is often discredited for it’s seemingly complex API and development hoops one must jump through. But if you have worked on a portlet project for a considerable amount of time, and then jump back to a servlet based project, you have a feeling that life just got easier.
This is all within the context of which servlet-based framework you might be working with, but overall things are a bit easier when dealing with one request and response.

What if you didn’t have to worry about portlet development gotchas anymore? What if you could develop portlets with the ease and hassle free life that you have with good ol’ servlets? Well, I’m here to tell you that this can be partly achieved with JSR-301 portlet bridge technology.

I encourage (actually I dare you) to those who have never even touched a portal to take the JBoss Portlet Bridge for a test drive. It takes 1 download (GateIn bundled with JBoss) and one maven archetype to get started. You can choose from any combination of plain JSF, Richfaces, and Seam with
mvn archetype:generate -DarchetypeCatalog=http://bit.ly/jbossportletbridge from the command line.

If you run into any questions or special usecases, we have 7 videos which demo and walk you through just about anything you could think up.

And for those that like to have a refcard by their side, you can get all the information you need about the story of portal technology and configuration drill downs here:

From “Mastering Portals with a Portlet Bridge” DZone Refcard:
“A portlet bridge allows you to run application frameworks like JSF in a portal environment without needing to know anything about the underlying portlet API or portlet concepts.”

And if all that wasn’t enough, I will be giving a 50 minute talk at JBoss World titled "Making Portals Cool: The Compelling Advantages of a Portlet Bridge" where you can come and personally track me down and specifically tell me about your problems, pains, or happiness with the project or the world in general JBoss World will be located in Boston from May 3–6.
I think early bird pricing ends this Friday (April 8th), so you better hurry if you want to save a little cash.

Richfaces 4 just reached Milestone 6 and now would be a great time for the community to step up and check how the components run on mobile platforms.
First off, Richfaces 4 currently does not offer mobile support but it is definitely the direction they are heading. And the RF team has taken all the necessary steps to allow the client side code to be extended and improved by way of jQuery.

Today I am going to add touch support to the RF drag and drop component. We all know that touch events and gestures are not the same as a mouse click. So one must consider a couple of different approaches before implementing a final solution:

1) Override the default touch events with their mouse counterparts.
This is easy since you are basically overriding the default functionality of touch and gesture events. There are 3 mouse events to replace to get this component working:
touchstart,touchmove,touchend

2) Extend jQuery core components and add the “drag” functionality alongside “touch”
A little more difficult and fortunately the jQuery team is working on the mobile upgrade to ui.draggable – so this should be available in the next few weeks/months.

(tested on live iPhone4 and iOS simulator iPad)

I originally started out using the touch and gesture events to do the drag and drop. This allowed for a smoother UX but unfortunately, the internal plumbing of Richfaces required a complex extension/wrap of rf.ui.draggable (to add the new touch functions) and some custom bindings like rf.Event.bind(this.dragElement, ‘touchstart‘+this.namespace….) in dnd-draggable.js.
In the end, it was just easier for me to use this script and re-map the 3 main touch events.

I looked at many different approaches starting with SenchaTouch which btw is pointless if you are going to leverage existing jQuery, then moving to a few different jQuery utilities.
The basic question here, which can be applied to any component framework, is “What’s the best mobile approach for supporting product xyz?” Every product out there that touches the UI has to cross this gap. Touch interfaces today… tangible UI’s tomorrow… and the vicious cycle continues. And majority of the time, the best way to get started is to build an emulator so that your product can work today. This will buy you the time to build the native functionality that takes full advantage of the target platform.
Unfortunately the script I used here doesn’t always work and there are still a few more components in Richfaces that do not work with this duck punch approach. So I will try to make this a series and blog about & fix the other components on mobile platforms.

The old days of drag and drop are not as simple as they used to be. With multi touch surfaces you have the ability to accelerate your drag and throw it across the page, rotate it, and auto scrolling when you drag the object off the page, etc... Just something to think about when designing a similar component.

One trendy technique that I often use in Photoshop (for buttons, nav bars, etc…) is a gradient that slightly variates from its base color with a hint of inner shadow (for highlight).
This used to be a pain in the royal ass to implement with html/css2, but now is amazingly simple with CSS3. Not only is it simple, but you can also create a sort of “gradient template“ to be reused. Kind of like a “style” which can be applied to any element in Photoshop.

First off, this is how I would normally do it in Photoshop:

1. Create the element – a button in this case:
   


2. Create your gradient. Gradients that are hardly gradients seem to give a nice appearance and body to the design. Meaning you start with a base color like #6c291f and move up the scale to #e42a00.
   
   


3. Next you add an inner shadow to give it a glow like effect. Again this too is based on your gradient color.
   
   


4. Here is the end result (from Photoshop):
   
   

Now, let's do the exact same thing in CSS3 with 1 step.

This tested fine across all the latest browsers (Firefox 3.6+, Latest Safari, Latest Chrome, and who cares about IE

1. Simply use the brightest part of the gradient color from above (#e42a00) and substitute it as the background color below:
   

    1 button.red {
    
    2  background: #e42a00 mozlinear-gradient(90deg, rgba(0, 0, 0, .3) 33%, rgba(255, 255, 255, .1) 123%);
    
    3  background: #e42a00 webkitgradient(linear, left top, left bottom, from(rgba(255, 255, 255, .1)), to(rgba(0, 0, 0, .3)));
    
    4  border-radius: 7px;
    
    5  mozborder-radius: 7px;
    
    6  webkitborder-radius: 7px;
    
    7  border: none;
    
    8  box-shadow: 0 0 6px rgba(255,102,102,1) inset;
    
    9  mozbox-shadow: 0 0 6px rgba(255,102,102,1) inset;
    
   10  webkitbox-shadow: 0 0 6px rgba(255,102,102,1) inset;

   
   


2. Here is the end result (from Firefox):
   

Notice from the css code that we are only using one color? This is so we can easily create a super class that allows us to override its functionality. In the end all you would need is one line of code for background color to create a button for every color that exists with the same style from above applied to it.

Now to create a button using the same “style”, you would only have to create a class that defines the background color and inner shadow highlight. i.e….

1 button.lightblue {
 
2  background-color: #41b6ff;
 
3  mozbox-shadow: 0 0 6px rgba(55,243,255,1) inset;
 
4 }

This would give you a button like this:

The only part that isn't really flexible is the inner shadow feathering. It is currently set to blur the shadow by a fixed pixel. It would be awesome if you could blur by percent as this would allow the gradient filled element to be resized dynamically and maintain the aspect of inner glow.

I've always heard good things about Jazoon and I got to experience it first hand this week. Definitely one of the larger conferences based in Europe, I was impressed not only by the venue but also with the star studded line-up of talented speakers/developers.

I was pleasantly surprised to see soo many talks about portal technologies. And people weren't talking about the spec or the technology itself, but about specific usecases - which is really cool. However, Andy Bosch did an excellent job of explaining the JSR-301/329 portlet bridge. My talk was more vendor specific on the JBoss Portlet Bridge and the features that we offer with Seam and RichFaces, so it was great to have someone there to explain the spec in detail and give a non-vendor specific view.

Andrew Lombardi announced his love for JSF and that the Wicket folks may/will begin to focus on a better component library community. I hate to mention JSF within the same paragraph as Wicket but when a developer at XYZ corporation wants to implement some usecase that makes use of a lot of different components, 99% of the time they will look to JSF and its many component libraries/communities. Not to get into a holy war here, because of course Wicket has a different way of handling it's components - and an overall different (better) way of handling the model and binding of components. The one thing that is missing from Wicket (in my mind) is heavy focus on polished component libraries and communities.

Matthew McCullough put on a great show with his Maven 3 presentation. The use of screenflow and his rate of speech were right on the money. It has inspired me to try just a little bit harder with my talks.

The Arquillian talk by Dan Allen and Aslak Knutsen ended as a great talk and shirt throwing fun. Of course, a few of the audience members had to pay the price of Dan's throwing arm - aim at the back row, but hit someone in the middle row with alot of force :D In all seriousness, Arquillian is taking the testing world by storm so you better jump on the train or get out of the way.

There were many other great talks given by other speakers. So, it was definitely a good knowledge sharing event.
Overall, I had a great time and met a lot of people whom I have only talked to through twitter and email. For me, it is soo much easier to blast or praise someone online when you have sat down and had a beer with them - but that‘s just me.

About a year ago, I decided to start creating screen casts for the JBoss Portlet Bridge open source project. As a manager of a relatively small, niche project, it is easy for me to try new things that can only improve the community around the project - or serve as a learning lesson for myself. Screencasts are nothing new to the development scene, but my goal was to liven it up a bit and make the outcome seem more professional and well produced. At the same time, covering all the important facets of managing a community like community member recognition, to getting started, and so on.

Coming up with a topic

This doesn't seem like a hard task, but it can make or break your idea. You don't want to base your topic on generic phrases or buzzwords. Of course, to get someone interested in your project, you may need to use a mainstream keyword in your title. But don't be untrue to your viewers. This is your name and reputation on the line, so give the community what they want by evaluating forum topics, in-house support requests, wiki articles, or current blog posts about your project.

Take a look at this: You might say, "Why not just use the core topic and tag the basic stuff?" - Well, tags are cool and all, but they are platform dependent, so I use a double-fallback with the title. Of course I still use tags, but when you post the title in your blog, twitter and wherever else, you will need the all-in-one, "Google friendly" title.

And lastly in choosing your topic, remember we all have roots as an end user of someone's framework or product, so I always envision myself as the user. This is best done by creating a screencast for a common customer support request or forum question, heck you could even use your FAQs as "season 1" for your screencasts

The Introduction

As an open source project manager, developer, community promoter, marketer, designer, etc… we have many hats to wear. Since I have a design background, I like to fire up After Effects, Blender, and other cool video creation programs and make a kick-ass intro. Most developers don't have this capability/luxury, so it's up to you on how far you want to take your intro. Typically, just some kind of view with your logo and a background image will do.

If you know how to use After Effects, or want to use the intro I created for this video, I have uploaded the source .aep file for you. Feel free to use whatever parts from it you want.

I also use music and different sound effects, (even extracting the vocals if necessary) to get the right effect. There are some great creative commons/open source music sources like:

• http://ccmixter.org
• http://www.jamendo.com
• http://creativecommons.org/audio/
• http://opsound.org/music

The Audience

Just like writing a book or article, this may be a first time user of your project, or it may be a seasoned developer. So know your target audience. If you plan on doing a series of ongoing screencasts, definitely make your first episode at a very beginner level. This will allow you to reference it in the future with more advanced screencasts.

Prerequisites

Explain the preparation steps clearly - environment variables, 3rd party downloads, utilities, etc.. Create a wiki or blog post listing all the requirements for users to follow along with. Show a screenshot of that article which you just created in your video before you get started.

Branding

I always start my screencast with a view of the project home page and a brief explanation of navigation and making your way around the project site. You want to drill this page into your users head and this is the best way to do it. You may have great forums and FAQs, but your users may have a hard time finding it... this is your chance to train the community on the hard work you have put into your project.

Be Realistic

Go through a dry run, but don't make it "too" perfect. You are guaranteed that many viewers will have some kind of problem while running through your demo, so when it happens to you in the screencast, don't edit it out - leave it. This is important because it's something every viewer can relate too. At the same time you want to keep in mind NOT to leave in your (or too many) mistakes. There is a fine line here of confusing your audience vs. letting them know that you are human and may face their same problems.

Create a script (if you need it)

For some folks, adlib and free handing this kind of stuff comes natural. Not for me. While going through a dry-run and making sure the screen cast is going to work as planned, jot down the notes that come to mind as you're working. This is important because you will often be too focused on speaking clearly and getting your point across during the actual recording. It's nice to have a set of reminders to look at.

Open Source and Commercial Tools

Onto the fun stuff, so now you have everything prepared and you're ready to start the recording. First, you need to get yourself a screen recorder and depending on your OS, I have listed a few options below.

Mac

If you are lucky enough to own/use a mac for your screen casting projects then I highly recommend using ScreenFlow. The intuitive UI and ease of creating powerful animations make it worth the money. Amongst all the screen casting tools available, this is hands down the best one I have seen. A trial version is available, but it will watermark your video on export.
However, the very kind folks at ScreenFlow hooked me up with a coupon code for the readers of this article. It will give you 10% off the original $99 price tag, saving you $10! Use discount code CPN9040717399 to receive and extra 10% off your purchase. Thanks Christine!

Windows

I used CamStudio http://sourceforge.net/projects/camstudio/ for a short project quite a few years ago, and I have no idea what is out there on the free & open source scene today.

Linux

A quick google search revealed a few (mostly ffmpeg based) but I'm sure there are more out there, so please let me know in the comments if you know of a good one.

• http://live.gnome.org/Istanbul
• http://xvidcap.sourceforge.net

Here are a few more tips and recommendations for recording and publishing:

• I bought a decent set of headphones with a microphone which seems to put me in "the zone" a bit more than using my built in laptop microphone.
• I think it's cool to actually record video of yourself usually for the first introductory video or at the beginning when it is mostly you talking. People are not going to be watching you talk, they are watching your screen actions. Be sensible about when to use video of yourself talking.
• If you mess up or get tongue tied, don't stop the recording. Just take a deep breath and allow a few noticeable seconds to pass, then start over. You will see your pause in your wave form visualizer and you can go back and cut it out when you are doing your final editing.
• Keep your rate of speech just a bit above or at conversation level. I made the mistake of not keeping a script nearby in my first few videos and it is definitely noticeable that I am thinking about my next steps while I'm talking in the screencast. It's not fun to listen to and makes you sound like an amateur.
• Cut out as much white space as you can when doing final editing and keep your screen transitions smooth when doing multiple takes or pausing while your wife screams at you to take out the trash or to answer the phone. Don't make your audience sit there while you wait for a server to start up. Cut out startups and any other tasks that are repetitive and boring. Every second counts and you don't want to end up with an hour-long screencast.
• Make jokes and make fun of yourself. Sure you are offering value by allowing your viewers to get tips and tricks first hand from you - the expert But simple entertainment and your character can increase your viewing audience, or simply make you more approachable when speaking at conferences, etc...
• Use time-bookmarking features in the comments. I think this is the greatest feature of screencasting and may even replace user guides or other documentation in the future. Unfortunately, the platform (vimeo) that I use limits this feature. Youtube does a great job at it and allows you to link to a specific time, down to the second, in a video - even external linking is allowed. With vimeo, all you must do in the comments is find the minute/second you want to mark and insert it into the comments as (7:31) - with the parentheses. This tells vimeo to render a link for that marker, but the big drawback is the entire video must load first, and you cannot access this marker with a GET parameter like youtube.
• And since youtube only allows 10 minutes or less for the length of your video, I have been using vimeo to publish all of my screencasts. Here are the export settings I use in ScreenFlow to allow users to view my video in HD format:
  • H.264 codec
  • dimensions 1280×720
  • bit rate 3000 kbits/sec (optimized for “download”),
  • key frame every 30 frames (frame reordering on), using whatever frame rate you shot in.
• As for ScreenFlow tutorials, you can find out how to use all of the functions and features here http://www.telestream.net/screen-flow/demos.htm.

The rest is up to you. Whatever tutorial or product review you are trying to get across to your audience, remember to be punctual, upbeat, and funny! As of this writing, you can view the following screencast where I attempted to apply the concepts mentioned here http://www.vimeo.com/8752541.