replicator.org ... raising the abstraction.

We finally integrated our new license management, but don’t panic, alpha testers automatically get a Upload license installed that runs until the first of July.

There is not so much new in this release so far, but we prepared a lot for making SharedSafe a serious product. We created the first part of a complete product licensing infrastructure and are really proud of it. It does exactly what we need and is pretty simple to use.

So there is this new tab in the Configuration tool, I’ve showed you before in a previous post. After the installation of build 1611, there should be exactly one unpersonalized license:

And we have integrated new Application Icons, and we think, great ones, which finally match our product Logo :)

Besides preparing the website, the next steps are:

Notifications

I know how I can be happy. Do you know? And if so, do you live it?

There are practices that will lead to a happy life and – also important – to a good relation with one’s work. But the problem is – perhaps the most profound one – that we just forget about all these best practices most of the time. So with this post, I’d like to share my personal manifest that should guide my daily life:

Daily Work

Prioritize first!

One of the hardest mental tasks is to prioritize work, so this should be done at first in the morning. For me, prioritization is just finding out what annoys me most:

Do tasks that annoy you first.

Finding out what annoys me is not easy, but one of the most important tasks in my life to keep me sane. I try to ask that question every morning and try to fix the problems in the same day.

If there are annoying tasks that can’t be “fixed” in one day, I think about canceling it. Learn to say “no”. If it is a project and I assume it will be annoying tomorrow (because it was yesterday and the weeks before), it’s even more important to get rid of it.

Happiness depends on being relaxed and pleased after each day, otherwise our lives go into the wrong direction. There is no such thing like “but later”. Life is now, and we all know it, but social and environmental pressure keeps us thinking otherwise. Brains fear change, but change is almost always a good thing.

That leads to a simple rule: Never accept annoying tasks that take longer than a day!

Don’t trick yourself into getting a rose colored perspective.

One of the next steps in personal computing will be Personal Process Management: Programming for the end user.

Combine new tablet devices like the iPad with the ease of creating a concept map like Instaviz and the power of programming.

Graphical programming has been blamed for not being able to capturing enough complexity, but – for a certain types of applications – it is sufficient, if not a lot more capable, because it may blend the visualization of processes with their semantics and live feedback.

Why to use PPM

Personal Process Management is not an obvious requirement, but automating tasks, which are repeated over and over again, sure is. Here are some ideas:

• Home automation is one area that needs configuration and simple programming for which an tablet would be the ideal device.
• Email forwarding and sorting sometimes requires more than an out-of-office reply.
• News filtering and classification may be the killer feature to keep you up to date with less but more precise information.

There may be some advanced application areas. I can imagine to use PPM to configure routings for web-services, programming failover scenarios, and – in general – event routing, that defines what to do with all the events that reach you on your various devices.

The current state of user interfaces is disappointing in the sense they fail to scale. Put thousands of entries in a Listbox and expect a degradation of performance, put thousand nodes on the screen, and zooming stutters. Just one thousand and we need hundreds of thousands.

Virtualization is the pathetical attempt to improve the situation, spot-wise. Globally, when your favorite user interface once failed to build scalability in, the application developer must optimize the details, which is hard and often impossible.

What is wrong here?

Simple said, convert them into a document. A document that is dynamically formed while the user is entering data required to proceed.

Compared to Wizards, this has several advantages: All relevant information entered is visible at any time, and by entering more information, the document expands to form out the final result that contains a representation of all the previous choices.

There is no context-switch for the user, the page may scroll but valid data never disappears.

When users change their mind, going back to a previous page is not required, they just change the option and continue, the document reforms as data is entered.

This user interface pattern is named responsive disclosure, and I am a fan of it. Sadly it’s not so commonly used, probably because of the difficulties in implementing it.

Today I started integrating our license management tools into our new product SharedSafe (sry, there is no website yet).

The first plan was to integrate the License Manager user interface like the about box: placing a “License Management” button on the right of the “About” button, but then I got struck by a “too much buttons” paranoia and thought about directly integrating the license table into another Tab of SharedSafe’s Configuration tool.

It’s possible in .NET to reference and load Executables from another Executable, and because the LicenseManager user interface was already a Executable, it was trivial to create a Windows Forms Control from the inner part and reference it from the Configuration Executable. Here is the final result:

In my opinion, this is a much better solution than to pop up just another dialog.

Tomorrow I am starting to integrate the license checks and the Tray Icon notification that will appear when a license is missing.

Today I decided to move my blog from the self hosted Drupal installation to wordpress.com, but then I sticked with upgrading my Drupal installation and a blogging API so that I can author content from my Desktop Computer.

Things have changed lately and I wanted reduce all duties and focus on new products for my company. So getting away from Drupal was my goal for today, but it did not work out.

I like the style of Wordpress.com, the administration interface is usable (compared to Blogger.com) and the preinstalled theme rocks.

Uploading to Wordpress worked just fine using Windows Live Writer.

But – to make things more readable – I just wanted to change the font size, which is possible by editing CSS but costs $15. Somehow this is not right, I just wanted to improve the readability of my blog and I should pay $15 for? No, this price may be ok for more elaborate style adjustments, but not for changing the font size.

Then I looked for possibilities to convert my older Drupal posts to Wordpress. But I gave up after asking google for a while.

So I was setting up another free blog on Blogger.com to see what the alternatives look like. Windows Live Writer was able to post the same content without a problem.

It’s a shame that ClearType is turned on in WPF by default and does not respect the operating system’s settings.

While this may be a good default for large Fonts, smaller fonts look blurry and a lot like colored patchworks.

I personally prefer crisp, pixel aligned fonts. Reading ClearType rendered text distracts and annoys me.

WPF’s font rendering engine does not support pixel alignment, so the only option to make text more readable, is to switch off ClearType and hope that anti-aliased greyscale rendering improves the experience.

To change these settings, the registry editor has to be used. Here is an article that explains how to adjust the ClearType settings for WPF.

We need to change registry entries for that: Go to the registry editor, open the key “HKEY_CURRENT_USER/Software/Microsoft/Avalon.Graphics”. Here you will find a folder for each monitor:

Now, for each display, set the ClearTypeLevel to 0.

Switching off ClearType results in greyscaled anti-aliased fonts. The font is rendered with relatively slim stems, especially when vertical lines lie right in between two pixels columns.

Luckily, the contrast level of the text can be adjusted, too. Its valid values range from 1 to 6: 1 (the default) results in very slim text, 6 appears bold. For me, a value of 3 is perfect: small fonts appear bold, but they are now much better readable.

So, to finalize the registry settings: Set the TextContrastLevel to 3 (or some other value depending on your preference).

I hope this works for you like it did for me.

yours
armin

User interface libraries contain controls for editing data. For example, text boxes, radio buttons and buttons.

They combine data visualization with user input, which seems convenient for developers.

“Rendering” presents content to the user. Input processing handles the feedback the user gives back to the controls.

Obviously, these are two completely different concepts:

I assume that the the combination of input processing and rendering in “controls” is seriously flawed and causes user interface development to be perceived as hard.

Input processing needs to be separated from control rendering because they differ in so many ways:

In time

Rendering needs to be available at any time. As soon the presentation model changes, it needs to be invoked.

User input needs to be processed at the time a control is focused.

On the surface

To update only parts of the screen, rendering should be partial; it may modify only parts on the screen at a time. Visually, it is expected to work in parallel.

User input processing happens in one screen area at a time.

Of performance

Rendering must be fast to keep the eye pleased. It may be parallelized to run on multiple cores.

Input handling may be processed much slower in a single thread.

In implementation complexity

Rendering is conceptually simple: structured data is rendered to a bitmap.

Input processing is more complex, it maintains focus states, may handle text input and processes different input devices.

Of relations

Rendering just reads the data model and writes to the screen bitmap.

Input handling reads and writes the data model, it even modifies what is temporarily rendered and how (the view model). Additionally, it listens to events and maintains a set of internal states.

Of states

Rendering does not need to maintain temporary states.

Input controls often implement large state machines.

Because of these huge differences, a number of essential conflicts are present in all frameworks I know:

• The complexity of event processing and calling back into the application binds all controls to the UI thread, and so they may not respond fast enough for rendering. Therefore, incremental rendering is often impossible, rendering can not be parallelized, output must be cached and a lot of memory is wasted.
• Input controls maintain a lot of states, even when they are invisible the waste memory.
• Virtualization (the selective instantiation / rendering of controls depending on the visible area) is hard, because event handling and focus processing is not separated.

• Separation of the domain model and the view model gets hard, because the roles of the controls are not clearly defined.

To avoid these conflicts, input processing and rendering should be separated:

My suggestion to user interface framework developer:

Introduce the concept of sensor fields that have no rendered representation and instantiate the required input (control / logic) at the time they get used.

My suggestion for the user interface developer:

Render output-only “components” and overlay edit controls at times when the user actually requires them. For high performance applications, use a fast rendering library instead and overlay edit controls from your favorite UI framework when required.

yours
armin

What’s wrong with application software: In five words: It fails to act social.

The granularity in which components are talking to each other is the computer. The channels they are communicating with is the network.

This is not enough. Software needs to get social. Components need to talk to others via asynchronous messages. Messages that can be targeted or broadcasted.

Imagine a system where components can access and modify your personal tag cloud. Components can “see” their environment and act cooperatively to present or transform data.

New files and data flow into the system: Every component may be able to access and interpret them in different ways, presenting the user with a number of diverse options.

Data’s visualizations need to be integrated in a common user experience. One that is scalable, compatible with future hardware and input devices, a 2D zooming interface.

Data entered and edited can be shared. Users can collaborate, live edit and act on multiple version branches. Conflicts can be resolved visually.

Data is stored forever, it is never lost, all revisions, every change.

Data is secure, can be moved via network at any time, so can their visualizations.

Components’ code is treated like data, everyone can produce them, everyone can use them, security is built in – based on social trust.

An environment with a common UI, automatic parallelism, a spatially indexed database and infinite room for extensibility, socially.

Make your apps more like you, act social!

yours
armin

Notes:

• All the techniques for the above vision are available, someone needs to act.

• Browsers will fail as long there is a central Document Object Model.