The evolution of Windows 8 charms

It's unclear what inspired the name for charms. It may have come from the item of jewelry, or perhaps from wine glass charms which are used at cocktail parties in certain social circles to identify which wine glass is yours.

Whatever the origin, the charms feature quickly gained the internal nickname Lucky Charms from the breakfast cereal.

I'm going to skip the prehistory of charms and just look at the evolution of the charm set.

Early design explorations came up with a list of seven charms.

  • Search
  • Share
  • Play To
  • Print
  • Pin
  • Stash (I think this was sort of like a clipboard)
  • Lookup (I don't know how this was different from Search)

After a few more design iterations, the list of charms evolved to

  • Search
  • Share
  • Switch
  • Start
  • Devices
  • Settings
  • Language

(There's a long story behind the Switch charm, which I will have to tell some other time.)

Each charm opened a blossom, which was a radial menu that opened up around the charm. This blossom idea didn't last long.

Eventually, the designers settled on these charms:

  • Search
  • Share
  • Send To
  • Start
  • Connect
  • Settings

We're very close to what shipped in Windows 8. Just two more tweaks.

The first tweak is that the Connect charm was renamed Devices.

The second tweak is that the Send To charm was removed. The story behind this is a bit more complicated.

As originally envisioned, the Share charm was for social sharing: emailing a Web page to your friend, posting to your Facebook page, that sort of thing. On the other hand, the Send To charm was for sending data to another application, like adding an item to a to-do list.

During the summer, we discovered that when our interns wanted an application to receive data from another application, it was pretty much a toss-up whether they registered the application as a Share target or a Send To target.

What this told us that segregating the two types of data sharing was interesting in a theoretical sense, but in practice, people didn't really make a distinction between the two. A last-minute design change was made to merge the Share and Send To charms into a single Share charm, and made it cover both social sharing and application sharing.

A happy side-effect of this reduction was that the number of charms was an odd number, allowing the Start charm to be placed in the center.

Comments (28)
  1. skSdnW says:

    I know a lot of people hated the charm bar but I kind of liked it even though I never used it much. Settings to configure the magic corners and borders would have been nice though.

    Why are Win32 apps not able to be share targets?

    On Win10 Win32 apps can at least be a share source (Does not work on Win8, the show share UI method returns S_OK but does nothing (unless you are the system metro browser?)).

    1. Jan Ringoš says:

      > Why are Win32 apps not able to be share targets?

      Because then someone would actually use that feature and it wouldn’t be so easy to remove it later.

    2. Being a share target requires your window to be hosted in the sharing pane, and that negotiation uses a CoreWindow and Activation, but Win32 apps don’t have those.

      1. skSdnW says:

        That is the situation after shipping but did you not think about it during the design phase? Perhaps COM object people could implement while Windows takes care of a minimal UI for you. It would not have to support a lot of things, the important bit is just getting your hands on the share data and spawn your Win32 application.

        1. It’s harder than just launching the win32 application because the application needs to somehow embed itself in the sharing pane. (The design was that there would be two parallel worlds that didn’t interact with each other. This design worked when we moved from MS-DOS to Windows: MS-DOS apps and Windows apps live in separate worlds and don’t interact with each other.)

          1. Joshua says:

            I never experienced charms at all because Windows was very nice and made a 1px wide hitbox, which is almost impossible to hit when running in a VM.

            On the other hand, I did write several DOS apps back in the day that knew they were running under Windows and took advantage of multitasking. I never even tried to get a DOS app to open a Window, but I think I could have made it work. (I vaguely recall being able to run MCGA graphics as a windowed DOS program.)

          2. Gary Keramidas says:

            but Microsoft is wanting us to switch to snip and sketch from snipping tool and snip and sketch is about useless to me without outlook desktop sharing abilities. i’m not setting up some mail account just so I can share snip and sketch images, when outlook is all I need.

          3. GL says:

            It turns out that recent UWPs are no longer using a pane. Instead, they just open a new window if further interaction is needed to complete the sharing. I would say it wasn’t wise to believe the worlds would not need interaction.

          4. >This design worked when we moved from MS-DOS to Windows: MS-DOS apps and Windows apps live in separate worlds and don’t interact with each other.

            (1) At what point did you start to think you were moving from MS-DOS to Windows again? MS-DOS apps were both Bohemian and Luddite by design; it is not like Microsoft refused to solve a problem. (As Bill Gates puts it, computers were at the time an expense instead of strategic assets.) Traditional Windows desktop apps are, on the other hands, very social.

            (2) Microsoft vehemently denied there being two separate worlds, when it discontinued the “Metro” codename. Microsoft said Metro-style apps were just apps, only modernized.

            (3) If there are two separate worlds, it would be a supreme mistake to put something strictly related to only one of the worlds at the hub that connects the two worlds, i.e. Windows shell.

  2. Gee Law says:

    Interesting story! I always thought Charm meant magical spells (that you could invoke at any time). There’s a funny story regarding several translations of ‘Charms’ (by Microsoft or by its vendors). In Windows 8/8.1, the term for Charm in Chinese is literally ‘Super Button’. However, in the documentation (.NET projection of WinRT), Charm is translated into Chinese as charm in ‘charming/charismatic person’. To make things funnier, Charm in, the functionality that allows you to attach a decorative icon to a calendar event, is (or was) translated into Chinese as Charm in Windows 8 (i.e., Super Button), completely ignoring its actual meaning of ornament.

    I’m looking forward to the story behind the Switch charm. My guess for Lookup vs Search is that one is contextual while the other is global.

    1. Arun Philip says:

      While Raymond’s post is interesting in the historical sense of Windows 8, your comment is much more hilarious, seeing how ‘charm’ was interpreted differently in various contexts by the internationalization team.

  3. Keith Patrick says:

    As I was reading that last list of charms, I was thinking that Send To and Share should be merged…I hate redundancies in UIs and love generalizations, so I see those two and think that they are just two varieties of the same action (along with Play To, which itself is a flavor of Send To).
    Windows may still have something like that that drives me nuts – Share With vs. Security tab vs Sharing tab….I could never get a total feel for how they overlap, so I’m constantly wrestling with file permissions when I set up my file server

    1. Alex Cohn says:

      The interns that triggered the change were, beyond reasonable doubt, influenced by iOS concept of Share.

    2. Richard says:

      It is however a shame that they went with “Share”, because “Send To” is a command that already existed for Win32 and thus is more discoverable.

      Plus the social media connotations are actively harmful in a corporate setting. I’m not going to risk hitting “Share” when I actually wanted to copy it to a USB memory or send it in internal email, in case it went to MyFaceTwitter

    3. Keith P. says:

      I seem to have another recollection of that feature (that I really REALLY hated) whereby clicking “Send To” from Desktop would fail because it would try to launch Metro Mail, but it would fail because Desktop couldn’t send data to Metro apps (or something to that effect…I just remember Send Mail in Win8 was embarrassingly broken. I could really go on and on about recent apps that were released in an obviously broken state, like WinPhone Groove and Edge)

  4. Nik says:

    I’m still running Windows 8.1 on my laptop, since it can’t wake up from sleep with Windows 10, so I see the beloved charms about twice a day when the trackpad generates an erroneous “swipe from right” gesture. I curse them every time they appear.

  5. jon says:

    One of the shorter-lived Windows features. Was more time spent on its design that it actually lived for in release?

  6. JAS says:

    What’s the REAL reason Windows 10 smartphones got cancelled? They had the best UI design of all the smartphones. All it took was confidence but it was a pure inside scuttle operation. Nobody actually believes Courier II will see the light of day, it’s already been a year since we were sent chasing that Goodyear Blimp. Nobody actually believes XBox as a loss leader is worth more to the company than mobile. What’s the hidden planet called? Astronomers are looking for it night and day and figuring this all out is the only thing that will make UWP relevant to anyone.

    1. Ray Koopa says:

      Bad marketing and (in effect?) bad store? Always looked like that to me. A shame indeed.

    2. Mark S says:

      It got real old, having to rewrite Windows Phone apps between 7, 8, and 10. Of course, you only really had to “rewrite” the UI layer, but the class library projects were a pain too, because the supported platforms for PCL (portable) libraries kept changing, so it was never possible to reuse the same class library for all the platforms I wanted.

      To make things worse, to install the SDK for Windows Phone 8, you *had* to be using Windows 8 (which of course, many found unusable on a traditional PC). The emulator for 8 required advanced virtualization features on the processor.

      Little wonder that people weren’t banging down the door to pay money to sign up for a developer license!

      I actually did try — I released an app for WP7, which I would actually like to port to Xamarin — but was completely unsurprised that no one wrote apps. Shame too because I think the UI for Windows Phone was and still is far beyond the usefulness of the others. It still boggles my mind how clumsy it is to not be able to “switch windows” to move between conversations with different people, rather than having to hit back repeatedly within the one app.

      1. Keith Patrick says:

        This right here. MS’s strength has always been its developer support, but the UWP (aka Silverlight vNext) has been a confused mess. I’ve got tons of assemblies that have almost no dependencies and should thus be extremely portable, but I’ve had to recreate the project file at least 3 times, as MS keeps changing the underlying scheme (Portable -> UWP -> .Net Core -> .Net Standard (to work with UWP)) I like to think that .Net Standard is the “correct” packaging, but who knows? Maybe next year, MS will decide that having .Net Core and .Net Standard is too confusing and will do a new “MinCore” or something to that effect. Hell, maybe they just abandon it for WebAssembly (God help us all)

  7. Adrian says:

    This is the first time I’ve heard the term “charm” to refer to a UI element in Windows, even though I’ve been using and developing for Windows 8 and 10 for a while now. What exactly are charms? Are users supposed to know what they mean?

    1. Entegy says:

      How can you claim to be developing for Windows 8 and never encounter the charms bar? And what the charms bar is is explained in the article.

    2. skSdnW says:

      I guess they assume most developers used the preview builds and followed the Building Windows 8 blog ( ), charms are mentioned multiple times there although they never post a screenshot of the main charm bar AFAIK.

      I don’t think power users are expected to know because I don’t think it says the name anywhere in the UI (maybe in the first boot OOBE?) but inexperienced users will find it out when they read about the start menu in Windows Help and Support: The charms: Search, Share, Start, Devices, and Settings: “The charms appear on the right side of your screen. Swipe in from the right edge or move your pointer into the upper-right corner and then down to see them, and then choose the one you want.”

      (Windows 8 help does not work at all if you have online support enabled but if you switch the help to offline mode you can search for “charm” to find this information)

  8. Colin Jeanne says:

    In the original functional specs the name of the feature was “Lucky Charms”. We changed it to Charms because Lucky Charms already has existing branding and Charms still captures the feel of the original name. When the feature was transitioned to a different team early in Windows 8 I guess the new team readopted the original name as the new nickname. I was unaware that that name was still used since on our side we called them the Charms!

  9. The best design decision was to remove them though.

  10. Gee Law says:

    I followed the whole video. The most frequent phrase has been “incredibly easy”, which, sometimes, makes me wonder why the interns spent even a summer on their apps (of course the main workload would have been on the business logic). I am impressed by how much Microsoft was to invest for 100 summer-time interns to try out and promote WinRT. The second thing I notice is that all featured interns use WinJS, is there a reason behind this?

    Also checked out the slides. When viewed out of //build/ context, the constantly changing background makes my eyes bleed.

    1. I don’t know, but I suspect multiple issues at play. JavaScript is great for rapid prototyping: No “compile” or “link” phases. The underlying OS was rapidly changing, and it’s easier to adapt with late binding. Interns are probably much more familiar with JavaScript/HTML than C#/XAML. VS support for interactive design of UWP XAML was probably very primitive, possibly nonexistent. And HTML support was probably more stable and better-documented than UWP XAML at this point. And once you have a critical mass, you can take advantage of collective knowledge, tips and tricks, discussion lists, that sort of thing. You don’t want to be the only intern writing a sample in C++. You’ll have no support community.

Comments are closed.

Skip to main content