User Interfaces: Perceived and actual affordance

"According to Norman, affordance refers to “the perceived and actual properties of a thing”, primarily the properties that determine how the thing could be operated. Note that perceived affordance is not the same as actual affordance. A facsimile of a chair made of papier-mache has a perceived affordance for sitting, but it doesn’t actually afford sitting: it collapses under your weight. Conversely, a fire hydrant has no perceived affordance for sitting, since it lacks a flat, human-width horizontal surface, but it actually does afford sitting, albeit uncomfortably.

The parts of a user interface should agree in perceived and actual affordances."

(Taken form MIT Courseware)

Nitro on IOS 4.3

Why is Nitro disabled in UIWebView and full screen web apps on IOS 4.3?
Read more about it here

- More on this topic: http://www.theregister.co.uk/2011/03/15/apple_ios_throttles_web_apps_on_home_screen/

Contributing to the JBoss 7 Management Console

You want to contribute to the management web interface for JBoss ? Then this should get you going.

Codebase

Everything is hosted at github, The best way is to create a fork of either one of the codebases listed below and work on that one.

- Authoritative master: https://github.com/jbossas/console
- Most recent: https://github.com/heiko-braun/as7-console

Prerequisites

The console it self is developed using the Google Web Toolkit. You would need to make yourself familiar with the basics before we et going. The GWT SDK will be installed as part of the maven build. No need to fetch it on it's own. If you plan to work with Eclipse, then you should consider the development tools for GWT that are provided by Google. But please don't ask how things are setup correctly in Eclipse. We baseline on maven and that's it.

Things you need to know

Widgets

We build on GWT 2.2 without any dependencies on external widget libraries. However these is a growing number of widgets (org.jboss.as.console.client.widgets) that should be reused. We aim for keeping the overall number of widgets to a minimum.

But if you need anything that doesn't exist, take a look at the SmartGWT showcase, tell us about it and we'll then consider implementing it.

MVP Pattern

But one of the cornerstones is the GWT Platform library, which nicely abstracts the MVP pattern. It act's as a blueprint for the console design. A good introduction can be found here. (This is a "must read")

AutoBeans

Internal model representations are build as AutoBean's. They align well with the default GWT API and have build-in serialization support. A general guideline: Any domain representation that's used within the console needs to be provided as an AutoBean abstraction. This means that beyond the integration layer (backend calls to the AS 7 domain) entities need to be adopted.

This is necessary to provide a baseline for the data binding used across widgets. Take a look at the form abstractions, then you'll know what I mean. The CellList and CellTable API's are another example.

Discussions

We are using the AS7 mailing lists and/or IRC for discussions of technical matters, improvements, proposed patches, etc:

- https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

- irc.freenode.net#jboss-as7

Managing JBoss 7: Screenshots

To add some meat to the discussion, here are some recent screenshots of the current web interface. It does use a very reduced look&feel at this stage, that allows us to focus on the tasks at hand, without getting distracted too much. In the next iteration we'll look into adding some proper styles, with the help of our design friends from jboss.org.

Server Groups

Deployments (associated with server group)

Server Configuration (on a host)



Server Instances (on a host)

Managing JBoss 7: A task oriented approach

It's been several weeks now, since we started working on the management web interface for JBoss 7. Time to outline some of the general ideas and concepts the console is build on. If you are not familiar with domain management approach that has been introduced in 7.0, you should make yourself familiar with it before reading any further.

Conceptually the domain model consists of three different levels, that we tried to reflect within the user interface: Configuration profiles, server groups and host specific settings.



If you think of these levels as being layered atop of each other, then Profiles would be the bottom most configuration level that acts as a blueprint for the layers atop of it. Profiles consist of subsystem specific settings (i.e. JCA, TX, etc) and are referenced by Server Groups.

Server Groups on the other hand specify configuration properties for a set of Servers that run on different Hosts.

A Host is the top most and most detailed level. It runs Server Instances that belong to a particular Server Group.
While there are numerous ways to organize the information accessible through the web interface, we used a few simple questions to guide our decisions:

- "What are the primary tasks?"

- "At what frequency to these task occur?"

- "What's the impact on related configuration elements?"

The primary tasks already seem to be represented by the different levels described above: Changes to and requests of host specific information is something we expect to occur quiet regularly. This does cover use cases like starting server instances and requesting runtime state information (i.e. metrics).

Creation and modification of Server Groups will probably happen less often, except one specific use case, which is application deployment. Deployments are associated with server groups.

The least likely changes are going to happen on the profile level. I.e the modification of a thread pool size is something you probably wont do very often.

The outermost categorization looks as follows:

Now while this coarse grained organization nicely groups the primary tasks and allows you to focus on the goal you want to achieve, it doesn't give you any clues which configuration properties are inherited from lower levels. Some elements can be specified on a lower and be replaced on higher level (i.e. System Properties in profiles and server groups).

This problem has two sides: On the one hand you need to know where an inherited property comes from in order to change it, on the other hand need to know what impact a modification might have on higher levels (Think of a JVM property on the profile level that impacts all server groups).

This problem isn't solved yet. We are still working on visual distinction that allows you to clearly identify the source level of a configuration property and cross reference it accordingly. It might look like this:

Call for participation

There are plenty of other related topics that we can talk about, but that's it for today. If you want to participate, I would suggest you take a look at the following resources and let us know to what degree the suggested categorization makes sense.

- DomainManagementModelDesign

- jboss_7_0 schema

Stay tuned, we keep you posted.

"The future is bright and the present compelling ..."

Dimitiris about the release of JBoss AS 6 and the work on AS 7:
http://jaxenter.com/jboss-as-6-0-0-final.1-34623.html

Export Mac OS Mail RSS URL's

Neat and simple:

pubsub --client com.apple.mail list | cut -f3 | sed -ne '3,$p'