In my last post I used SharpKeys to remap the keyboard layout because of my intensive use of home and end keys. Great deal. Works really fine.
But this solution has one major drawback. At the office I use an external keyboard. In this case  I have the inverse of the annoying keyboard layout.

Changing the keyboard mapping to the current situation with SharpKeys is not a solution as the steps would be

1. Start SharpKeys
2. Enter/Remove mapping 1
3. Enter/Remove mapping 2
4. Enter/Remove mapping 3
5. Enter/Remove mapping 4
6. Write to registry
7. Logout
8. Login

It’s takes time, is stupid work and is error prone.

So I started searching again and found the tool called AutoHotkey. This tool supports anything around keystrokes, running macros and many more. And it also provides key remapping. The first intention was to forget the solution with SharpKeys and use AutoHotkey instead. But it’s not that simple.

Pro SharpKeys:

• The settings are written to the registry.
• The application doesn’t have to run to get the mapping work.

Pro AutoHotkey:

• Easy to change settings.

The double remapping solution

The solution that' fits best for me is as follows:

• Using SharpKeys to remap the keyboard to work best with the keyboard of the notebook. Let’s call it “Device settings”.
  This is the default setting of my device and no application is running to get this mapping done.
• Using AutoHotkey to remap to original keys when using an external keyboard. Let’s call it “External settings”.
  This mode needs an application to run. With external power supply and a very small footprint this is really no problem.

The Steps to switch to External settings or back to Device settings are:

1. Start/Stop ExternalKeyboard.ahk

Great, I love it. A little tricky but works really great.

I was really surprised how easy the key remapping was done with an AutoHotkey script. It’s that simple:

Home::PgUp
End::PgDn
PgUp::Home
PgDn::End

There are a lot of things to consider when coming to a decision about which notebook to buy. Among the obvious facts like cpu power, memory, ports etc. there’s another important fact to consider.
The keyboard layout !!

Some manufacturers are playing around with the layout that you even cannot find the key you are looking for when searching with your eyes. Hitting it while typing is impossible.

What are most misplaced keys?

• enter key (too small)
• right shift key (too small or at the wrong position)
• home, end keys (access via Fn-Key)

Depending on your computer usage you will not even recognize this fact. But if you are typing a lot you will despair on it.
And if you are writing source code, which is a per line writing, you will miss the home and end keys a lot. I can’t live without them.

So when searching for my new daily companion I had a look at the keyboard layout especially the size and position of the shift key and the position of the enter key. I couldn’t find that much business notebooks having the home and end keys as separate keys. We are talking about 12” subnotebooks. So what.

I corrected the keyboard layout with software. In my case home is “under” page up and end “under” page down. I just swapped this keys. Great. I really like it.

To change keys you can use the tool SharpKeys which is simple and great.

http://ts.fujitsu.com/products/mobile/notebooks/lifebook_p3_series.html

It was time for an update of the Tag Cloud Package introduced with the post Tag cloud for Umbraco CMS blog package. The bug removed is about having only two tags which caused a weight of -2147483648 for one of the tags.

If you already using this package just download and replace the TagCloud.dll.

If you are new to the package read the original post about my package at the introducing post Tag cloud for Umbraco CMS blog package.

Feedback is welcome.

Email, Chatten und gemeinsames Arbeiten an Dokumenten sind ja heutzutage allgegenwärtig. Das Problem der vorhandenen Konzepte ist - vor allem bei Emails - dass es keinen Kommunikationsfaden gibt, dem man folgen kann. Man denke nur an eine Emailkonversation zweier Partner. Nachdem bereits einige Mails hin- und her- geschickt wurden, wird ein weiterer Partner involviert. Spätestens hier entsteht ein Durcheinander, weil alle Beteiligten auf unterschiedliche Versionen der Mails antworten. Das "Textchaos" ist vorprogrammiert.
Auf die Probleme basierend auf inkonsequente Nutzung von Emails möchte ich hier gar nicht eingehen.

Google hat sich dieses Problems angenommen und Google Wave entwickelt. Das Grundkonzept ist denkbar einfach und die Umsetzung sehr beeindruckend.

Anstatt einer Nachricht, auf die eine oder mehrere Antworten geschickt werden, steht hier das Unterhaltungsthema, die sogenannte Wave, im Vordergrund. Es wird zuerst ein "Behälter" für die Kommunikation über ein bestimmtes Thema erstellt. In diesen Behälter schreiben dann alle Beteiligten hinein - und das live. Videos, Screenshots und eine Beschreibung ist auf der Homepage von Google Wave zu finden.

Das Werkzeug wurde erstmals auf der Google IO vorgestellt und fand bereits beim anwesenden Publikum sehr großen Anklang.
Seitdem rollt die Welle immer mehr in die Öffentlichkeit. Dass hier nicht nur positive Stimmen zu hören sind, liegt in der Natur der Sache. Eines muss man auf jeden Fall festhalten. Es war an der Zeit für ein völlig neues, auf den Erfahrungen und Problemen der Vergangenheit basiertes, Konzept zu entwickeln. Und Google ist das meines Erachtens sehr gut gelungen.

Wie die Welle weiterrollt und sich entwickelt ist abzuwarten. Es besteht auf jeden Fall Hoffnung für eine einfachere und produktivere Kommunikation. Vor allem wenn weitere Hersteller auf diesen Zug aufspringen (Und das hoffentlich so, dass alle "Wave" Anbieter zusammenarbeiten).

In Zukunft werden sicherlich viele Menschen mit Google Wave schreiben. Mal sehen wie viele "Googleschreiber" es geben wird ;-)

When defining rows of a WPF grid you can use several ways to set the height of the row. Automatic, absolute values or relative values. But there's no notation for percent values.

But instead of writing Height="25%" you just use the relative notation.

<Grid.RowDefinitions>
  <RowDefinition Height="25*" />
  <RowDefinition Height="75*" />
</Grid.RowDefinitions>

Using this notation with databinding

Assume we have a simple data class

and bind the two properties to the two rows of the grid

and assign the DataContext property

DataContext = new Data() { Percent1=25, Percent2=75 };

we get a grid with the first row's height set to 25 and second row's height set to 75 in absolute values. As you can see the rows have the correct height but they do not use the whole height of the grid. To get this fixed we need to use the star notation again.

We need to convert the values to get the visual result we want. And the conversion must be done at the data binding because it's part of the presentation of the data and not the data itself.
When working with WPF (not only in WPF) you should always consider if the logic is part of the presentation or the data being presented.

Converting the bound values

To convert the values we create a simple converter class implementing the IValueConverter interface placed in the namespace System.Windows.Data. We just need to implement the convert method adding the star at the end of the value.

When we now use the converter for databinding

we get the result we wanted to have.

Meine aufgezeichneten Rueda de Casino Figuren sind jetzt auch als RSS feed verfügbar. Damit bleibt man automatisch am neuesten Stand.

Hier klicken: Rueda de Casino Figuren abonnieren

Keine Ahnung worum es hier geht? Einfach hier nachlesen.

Related links can be very useful to give the visitor an easy way to find additional information. This could be a page on your site or even a link to an external site.
How can this be realized with Umbraco?

A built in functionality is not available addressing this issue.

But there's already an extension package available. It's called Related Links. The package provides a property type allowing to add multiple internal and external links to a document.

I really feel confident with Umbraco and it's flexibility. Hence, I always think twice before installing a package.

Working with built in Features

With a few steps we can solve this issue using built in features and even get more flexibility.

Create a document type

To solve this we introduce a new document type called "Alias" with two properties "Node" and "Url". For easier editing we add a tab called "Settings" and assign the properties to this tab.

We want to add documents of this type to other documents. Therefore we must set the Alias document type as "Allowed child nodetype" of the document type where want the aliases to add to.

Create an xslt file with macro

To render the links we create an XSLT file ListAliases.xslt with the corresponding macro.
In this xslt stylesheet we iterate over all child nodes and set the href attribute according to the kind of link.

Use the macro

The last step is to use the macro in the template where the related links should be displayed.

...
<h2>Related</h2>
<?UMBRACO_MACRO macroAlias="ListAliases" ></?UMBRACO_MACRO>

Working with the solution

To create related links we now just have to add a child node of type Alias to our document for each related link we need.

In this child nodes just set the Node or the url to link to.

In this example we have two related links - one external (Umbraco) and one internal (My Blog).

The resulting page could look like the following

Key Benefits

• First of all. A document type is the main feature of Umbraco and therefore this solution should work for all future releases and for all installations. See also CMS structure granularity - not only in Umbraco.
• You can decide when to publish and when to remove the link by using the built in functionality available for all nodes.
• This solution is very extensible. You could add additional properties to the Alias document type for instance:
  • an image to be displayed next to the link
  • a  flag for a special sort criteria
  • a description which is displayed with the tooltip of the link.
  • You could introduce a document type called "Alias group" for grouping the links in for instance "Related" and "Depends on".
  • You could even manage your links at the root of your content tree to reuse them at different nodes.

Schon wieder eine Woche vorbei. Und natürlich wurden etliche Figuren getanzt und auch "neue" gelernt.

• Ataqua
• Daiquiri
• Directo
• El fin
• El train
• Enchufe
• Enchufe doble
• Enchufe moderno
• Enchufe y quedate
• Enchufe y media
• Festival de patines
• Paseala
• Paseala complicado
• Pisa
• Setenta y uno
• Suelta

Wie immer sind Kommentare und Korrekturen willkommen.

What is the content? What is the structure of the content? What is a document type? What is a property of a document type? How can I reuse documents? Flexibility versus usability? How to avoid different appearance of same kind of data? How to extend the system on the fly?

These are some questions that come along when designing the internal structure of a CMS based website. Depending on your CMS some of them will be addressed with built in features, some of them could be done with some effort and some of them may not be solvable.

Here I want to show a very simple case study concerning what could/should be a document type.

The site

We want to create a site providing news items. To keep it simple we forget about authors, date to appear, date to disappear, categories and so on.

I will use the naming of the Umbraco CMS for this case study.

Straight forward Solution

Our document template (NewsItem) contains only one dynamic property called "Content" of type "Rich text editor". The title of the article is the node name itself.

Really simple. Let's write articles. Create a new content node with a meaningful name. Fill in your text in the Content area. Publish it. Ready.

The authors of the content will write text, insert some pictures and everything will be fine. Style sheets are defined well, so all articles look just the same.

Content without structure

After a while you will realize that the authors add a section for related links to external resources in the content text. Some of them write a heading called "References" listing all links with a bullet list others add a bold text named "Related" and provide the links with a comma separated list.

The result are articles formatted in many different ways destroying the corporate identity of the site.

Approach 1

The first approach would be to tell the authors that they should use a heading, call it "References" and to list the links using a bullet list. Maybe it would solve the problem if the authors work really consistent. Let's face it. Don't event think about this approach. You are using a CMS!

Approach 2

The next approach would be to add a property called "References" of type "Rich text editor" to our document type. This property would be used to write the links (again using a bullet list). The difference would be that the designer can decide how to call this section and where to place it. Even the formatting could be easier changed. Still not happy? Right.

The authors must still ensure that the formatting of the links is consistent (bullet list). Changes of the formatting could only be done by rewriting each article (ok, style sheets would also help for some situations).

The solution

The solution in terms of a CMS is to introduce another document type called "LinkItem" containing a property "Url" of type "Text string". The Friendly name of this link would be again the name of the node. This LinkItem is then declared as a "Allowed child node type" of the "NewsItem" type.

To add related links to a news item the authors add one child node of type LinkItem for each link.

Benefits

With this solution the authors now can again force their energy to write content and to provide related links. The designer can decide where to place the links, how to format them and even if they should be hidden in a special situation.

That's why we use a CMS. Isn't it?