Why Do Companies Still Use Microsoft Windows For Displays?
shkspr.mobi
shkspr.mobi
We oftentimes ran into the situation where a potential customer really liked our solution, but wanted to run Windows instead of Mac OS X (this was arguably a lot tougher in 2005 when we started, and less so after the iPhone hit). There were a variety of reasons for this:
- Windows was the OS that the company was also using for employee machines, so they knew it.
- The IT department only wanted Windows machines on their network (our grand solution for this was that our machines were sold with direct support and did not need to run on the customers network, which also removed a lot of security pain)
- The customer was afraid of Mac OS X because they thought it would not be stable enough
But most importantly, it came down to simple risk aversion. The employee at a big company that was internally responsible for the 'digital signage' project, would base every decision on which choice would be less risky for his carreer in case the project fails. Lets say they roll out digital signage, and it costs a lot of money, and it doesn't work right. In that case, the employee needs to be able to defend himself against all sorts of questions: "Why was this product chosen", "Why was this vendor chosen", "Why was it implemented in this way", etc. In that case, being able to answer "We choose Windows, because it is the de facto standard" is better for the career than having to say "It seemed to be a stable product". Out of this reason alone, we found companies would choose a solution where they knew that it was far worse (less stable, less flexible, less features) simply because on paper it looked less risky.
A lot of professional grade display screens also come with a built in computer running embedded Windows. Although for web based signs a Raspberry Pi works really well: https://shutdownscanner.com/Blog/Posts/Raspberry-Pi-Digital-...
The problem arises if people buy the lightweight hardware like a Pi and then try to run the complex stuff.
Also, most people seem to ignore just how important the backend / cms system for these installations is. The content that is deployed on systems is already out of sync as soon as you plug the systems in :) I still remember fondly how I watched one of our competitors distribute content (on a digital signage fair) to his systems using WS FTP for Windows. That's not a solution you should sell to a demanding customer, he'll simply call you whenever he wants a new image on there.
The Pi has a surprisingly powerful GPU but I've not tried HW acceleration from the browser. Something to look into maybe.
Customers want cheap and I don't blame them but it took a second iteration of the shitty Atom line, one with a proper GFX card from Nvidia to have this display in any usable capacity. Atom/Netbook is absolutely not the way to go for Flash content. I would wager the Pi would be roughly identical unless you could leverage a beefy GFX card.
If you weren't using Flash, you could practically use anything. HTML5/CSS3 animations have come quite a distance but its definitely not 1:1 still.
> Windows was the OS that the company was also using for employee machines, so they knew it.
They understand it, have an idea about the cost and amount of support necessary. "They knew it" seems to convey that they were essentially stupid or not adventurous enough to try something else.
> The IT department only wanted Windows machines on their network
Again: a complete valid reason in my view. Here on this forum you have even people advocating that server and client in web apps should be written in the same language to keep things consistent.
> The customer was afraid of Mac OS X because they thought it would not be stable enough
You make that sound like there teeth were rattling in horror, but apparently failed to convince them that OSX would be stable enough?
I'm not a Windows developer or -user, indications that win 98 runs on my ATM also make me concerned.
But "muhaha, they are just stupid bricks for using windows" (no, you did not say that, but it sums the attitude) shows a lack of understanding and, as a consequence, does not advance the spread of alternatives into these environments IMO.
> "They knew it" seems to convey that they were essentially stupid or not adventurous enough to try something else. I did not intend to convey that they were stupid or not adventurous enough, I simply thought "knew it" would be a sufficient enough description. I did not intend "knew it" in a pejorative way at all.
> You make that sound like there teeth were rattling in horror No, not really, actually I remember discussions with big companies where those were the exact words ("Our IT department is concerned with the stability of this Mac OS X")
> "muhaha, they are just stupid bricks for using windows Again, no, I just tried to explain the seemingly irrational behaviour (for tech people) of choosing a technologically worse solution even though better solutions exists. I wasn't even talking about Windows actually, but about digital signage solutions based on Windows. I'd rather not go and open the box of pandora that is Windows <> Linux <> Mac OS X. Most of our competitors that ran on Windows (situation may have changed, I left that company more than 2 years ago) were on the feature side and in terms of possibilities worse than our solution (not only because it was easy to pull of a lot of things with Core Graphics really easy).
I really can't see where you read the "those people were stupid" attitude, but it may be a cultural difference, I'm not a native english speaker. Nevertheless, even if I sounded that way, it totally wasn't intended that way. If I were in a big (non-tech) company in such a situation, I might even decide in a similar way out of the above reasons.
I could type up 3 pages of my experience there, but I'll just say that because it was my first job: It took me 4 years to confidently identify the 3 points OP listed(that it wasn't me that had a problem), one more year of research for me to learn that living in the bay area put me in the middle of the tech-start-up scene that had a mindset like my own, and another year to replace all the expensive proprietary software tools on my resume with trendy open-source alternatives.... then I left.
The Videro solution is a full packaged system that you connect to a display and to a network (if you're connecting to wireless, there's a special remote UI that pops up after first start and lets you enter wireless info, much like on Apple TV systems) just runs. It usually connects to a cloud system, and then you can distribute content to it. It is really hassle free, which is also important for large scale deployments. (If one machine breaks, you can just pop it out, and put a new machine in, one click and it will receive all the content from the previous system and continue the job).
They use Mac Minis, with full-screen Chrome to run the slideshow, and I often see error messages on these (though typically from having dropped the wifi connection and not from an OS panic or other real error).
- One solution is to just display an error page (bad!)
- Another solution is to display a cached version of the page. Sounds great until you have to display stocks.
- The proper solution is to display a cached version, except for time critical data where you either go to the next piece of content, and if that's impossible, display the customer logo or some default fallback content.
This and thousands of other small configurations are what make up a good digital signage solution. The default web browser, being made for user interaction, doesn't cover it, obviously.
Here's a really, really, old demo of the software:
http://www.youtube.com/watch?v=pSvHp1LL4Po
That was 4 years ago, and it is running on rather old hardware.
I had a choice of implementing a machine controller with GUI in MacOS (System 7.5), some flavor of Windows, or even MS-DOS! Two factors influenced my choice:
1. Familiarity with the innards of a PC assured me that I could make it work all by myself, no matter what, even if it turned out to be ugly on the inside.
2. Looking ahead, and realizing that a bunch of MacOS development experience on my resume would elicit a yawn from most recruiters.
As for the display controller, today I'd do it with something like a Raspberry Pi.
It's surprising that a smart HN blogger can't put himself into somebody else's shoes for a second. When you're a manager and your boss tells you to go install some kiosks, chances are good that you're going to go out there and get some proposals. You're gonna pick whichever one of them best represents themselves, has a price that you want and seems like they'll be there when you need their support. You're probably not going to go with whoever is the most "cool" or "bleeding edge." You're almost definitely not going to try to put together an open source solution yourself just to save a few thousand bucks on OS licenses.
It's just as simple as that. Windows kiosks are in use because there are a lot of people out there selling Windows Kiosk solutions. If at some point another system manages to get a decent marketshare and has sales people out there writing proposals - then you'll start to see more of those.
My point is that no general purpose OS is immune from fault. All you can really do is remove or disable things which aren't absolutely needed to get your work done. In this case they should have disabled Windows explorer (which, by the way, is supported) or used one of the specialized cut-down versions of Windows (e.g. Windows Embedded 8).
PS - Although I will readily admit that Microsoft makes it insanely hard to licence Windows Embedded, particularly for SMBs. But Microsoft's licensing is far harder than it needs to be across the board, they have an old-mode mindset where they can charge more if they make the whole process harder.
Thai Air, the projector kept rebooting throughout the whole flight http://www.flickr.com/photos/kalleboo/3911989854/
Singapore Air, initial reboot as we were boarding http://www.flickr.com/photos/82365211@N00/2473197800/
Because the licensing costs are pretty small compared to the project costs.
Because there is plenty of tech support available.
Because Windows flash support is good.
Because there are plenty of developers who will customize it for you.
Because it is easy to add to the existing networking systems being used.
There are plenty of reasons to choose Windows for this kind of thing. why is the article even complaining that the OS is old? No need for cutting-edge here. (EDIT: Oops, that was in the comments section)
(LOL at the mouse jiggler software though!)
Any general purpose OS would have these problems
It's stable
Tech support is easy to find
Software can be easily demoed
A better title for the article would have been:Who's paying these shitty IT guys?
Recently we rewrote from stratch our software in Qt so it would run on Linux and Android, even on the Raspberry Pi.
The main barriers we found in Linux adoption were:
- Support staff only knows Windows. This gets worse when screens get installed in remote areas, like we have some screens at Manaus, in the Amazon Forest. There is just no one to support Linux there.
- Flash support state in Linux is unknown. Adobe seems to be discontinuing support for flash in Linux, and flash movies cannot be run on the Raspberry Pi or any ARM device.
- HTML5 is the next target, but even on Windows the embedded webbrowsers are not up to par yet on performance, in Raspberry Pi it is inviable. It cannot replace 100% Flash yet.
- Remote admin support on dynamic IP is great in Windows with Logmein, terrible on other platforms. Yes there's TeamViewer on Linux but it seem not too stable, not to say it looks like to be running emulated. Our customers don't trust it the way they trust Logmein.
That said, we are seeing increased Linux adoptions for some markets. If the Qt5 Blink-based webbrowser is more on par in performance with current desktop browsers, than the adoption may rise a lot.
EDIT: fix newlines
If you work in IT for any length of time, you come across people who use Excel as a text combiner to parse tabular text in ways similar to how a regex could, or have similar convoluted workarounds for any number of tasks.
In some ways, these are quite clever hacks.
In other ways, it's kind of sad as it obviously shows how badly GUI-centric "It's a fancy typewriter" attitudes toward computers have ruined generations of users by giving them substandard tools which they barely can make work for an automation task.
I'd love to see a "Signs in Stores-ix" as much as the next guy... but most people who do this are probably designers or businesspeople whose computer worldview doesn't extend behind Photoshop and Powerpoint. And thus, that's what was mandated on the displays...
Yep. Large parts of the finance crowd are Excel experts so it makes sense to use that. Why bother with regex when you know the Excel shortcuts, functions & behaviour off by heart. That plus I don't need to explain to IT/manager why I'm messing with software they haven't seen before.
For that reason, whenever i look at job postings, if there is any mention of Excel or VB script, i instantly close the browsertab... I wouldn't touch it with a 10 foot pole.
Slightly related. One of my professors wrote a 200 line matlab code to extract a column from a csv file, when all she needed was a one line "cut". The only language she knows is matlab.
Well, they know the windows platform and had windows machines lying around. They hooked up PC's to these TV's mounted high up on the wall, either mounted the PC on the TV or put it somewhere that couldn't be seen, and put powerpoint viewer on the PC's.
This might sound like a disaster, but the higher-ups loved it. And it worked quite nicely to my surprise. Windows can easily be configured to start the powerpoint file of your choice in fullscreen mode when the machine starts. Creating the material was as easy making a powerpoint.
So, in the end, the cost of materials and time was minimized because these guys used Windows + Powerpoint for their digital signage. And since they weren't using some buggy piece of custom software, it was fairly stable.
You may not like Windows, but it's a _fine_ computing platform. People get _work done_ with it. Personally, I'll stick with OSX.
I've changed a set of digital signs from running full screen IE on windows (with very long VGA cables) to chromium on Raspberry Pis. The new system behaves a lot better but there were lots of little things to tweak to get it running well. I wrote a short blog post with all the relevant configuration: https://shutdownscanner.com/Blog/Posts/Raspberry-Pi-Digital-...
A lot of the new TVs are smart and come with a built in android browser so you don't need anything else. We have one of these and run Pis on all the existing dumb TVs.
To be honest I'm more concerned when I see ATMs running Windows 98; at least these advertising displays can't do any real damage...
- The cost of a Windows license is tiny compared to the cost of the hardware and software.
- The cost of installation and maintenance: How much does it cost to pay someone to attach that screen to the wall and run wires around the building to the room containing the server?
- Back in 1995 it probably did make sense to use Windows, since it had wider support for hardware and good developer tools. Now that there is a huge amount of software written in the 90s for Windows, it's going to take a very long time to change that (if ever).
- Windows might actually be better for this even now.
At my current gig, we use SiteKiosk which locks windows down tight. It uses the IE WebBrowser control via ActiveX/COM/.Net/however the hell it works. Its basically IE but slightly shittier due to there not being a 1:1 between it and IE proper. SiteKiosk has some pretty powerful digital signage features you don't really get from a Windows Embedded scenario. One feature of 8.1 I was looking forward to was "kiosk mode" but with WinRT being blocked from talking to localhost, except through a hack (yes, fuck you Microsoft) it was stillborn for my tastes.
.NET apps are ClickOnce or xbap, which is basically pre-Silverlight. This is the suckiest part. SiteKiosk can run normal applications and Silverlight with no problems but it took SL 5 to get proper COM support and it isn't terribly easy to make your normal .NET library "just work" so that wrapper for a card dispenser isn't as easy to leverage. Due to the low number of these apps (2), we haven't bothered migrating away from shitty xbap.
The largest amount of applications use typical wamp running a lightweight PHP framework and sometimes MySQL as localhost. Some are completely or partially Flash driven applications as well.
SiteKiosk and leveraging IE lets us focus on perfecting the experience though I've become complacent. IE development is just too slow now and testing in Chrome with superior dev tools are absolutely essential. The problem there is we can easily paint ourselves into a Chrome-only corner if we aren't careful.
Leveraging the POS equipment like barcode readers, card dispensers, or printers are the only thing the web proper isn't really suited for unfortunately. This may be where Windows has much more leverage due to their driver model. Most equipment we interfaced with had a .NET library or simple instructions of use with P/Invoke. I saw very little (<1%) that had anything to do with Linux and in typical fashion wasn't something to simply use via something like PHP or Ruby/Rails. Maybe we chose Windows friendly vendors, though, so take this with a grain of salt.
Combine that with customers who want to use Windows tools to configure/upload to their signs and IT folks who are "comfortable" with Windows on their network and voila, mutual lock in.
Because it's cheaper. All you talk about is license but what about actual work of setting it up and making it work?
Also, you really think that only WinOS kiosk systems are crashing? You really are so ignorant to think that LinuxOS kiosk systems never crash?
"raspberry pi" -- 1,060,000 results
"linux" -- 4,890,000 results
"os x" -- 6,910,000 results
"windows" -- 32,800,000 results
Edited for clarity.
Just because you don’t see the point of an Apple product beyond “ooh shiny” doesn’t mean others don’t.
I work for a global company where > 50% of people work from home offices and > 90% of our staff use Macs. I can only actually think of 2 specific people (out of 200+) that use Windows, but Im sure there are a few others, and some Linux users.
Are you suggesting that all these people, many of whom are in countries with lower wage standards, pay “extra” just to have a shiny apple logo on their desk at home that no one but them sees?
I'm not aware of any evidence of this, and I don't even remember any of my Apple fanatic friends even claiming this. Any references?
>Are you suggesting that all these people, many of whom are in countries with lower wage standards, pay “extra” just to have a shiny apple logo on their desk at home that no one but them sees?
This is a dishonest way of having a discussion.
From my personal experience, yeah they do last a lot longer than my other PCs, maybe with the exception of ThinkPad. Mac hardwares are very strong and well designed. Most other PC manufacturers needs to cut cost from every single component, thus they won't be able to use the highest quality components.
I've seen dead signage and kiosks from all the main OSes and OS/2. It happens, what I'm interested in is automatic reboot methods...
https://plus.google.com/108455147088522730235/posts/bjQyyUip...
Seriously, complaining that an out of disk space error message pops up on signs? I have a Slackware Linux box that has been running for years. Probably ran out of disk space a dozen times since I first installed it so I know from personal experience it's not immune from running out of disk space.
In theory, this developer could just use Mono to run his .NET app on Linux. But that requires them to learn how to do that. Personally, I've never found a clear tutorial on how to take a .NET GUI app that you've just written in Visual Studio and get it running on Mono. I haven't looked in several years, so I thought I'd give it a try right now. I googled "visual studio mono" and these were the top 3 results:
http://www.mono-project.com/Visual_Studio_Integration
http://www.mono-project.com/Working_with_Mono_and_Visual_Stu...
http://www.mono-project.com/GettingStartedWithMonoTools
None of those are clear at all. The second page links to this screencast: http://www.mfconsulting.com/product/prj2make-sharp/tutorial/...
which illustrates how to use this thing with Visual Studio 2003(!) and demonstrates part of the problem: the Mono version of the app looks noticeably different from the native Windows version. Sure, this can probably be fixed, but it's yet another issue that the dev has to spend time learning how to hack around.
This situation results in substantial cognitive overhead. It's unlikely that an average .NET dev will be able to go into work, install this Mono plugin, compile their app using it, and present to their coworkers, "Look! We don't have to change our process at all, and we can deploy our app on the latest Ubuntu with a minimum of hassle."
It's hard to imagine how wonderful it is to build .NET apps compared to dealing with Qt, because Visual Studio's GUI designer is just so good. Suffice to say, there are a lot of network effects that keep a developer mentally locked into Visual Studio's paradigm of "here's how you make this GUI form;" a paradigm which is immensely difficult for Linux to support natively.
I think it's a mistake for Linux to even try to support this, though, because it's probably focusing on the wrong problem. The way to beat Microsoft is to make it so easy to write cross platform business apps that newer generations never even bother figuring out how to install Visual Studio. I think the web browser will be that solution within the next decade. It's not quite there yet -- it's way easier to get a GUI workflow up and running using VS's designer -- but it seems inevitable. So if you share the author's concerns, then the best course of action is to write some quality tutorials for your web frameworks, and to invent easier frameworks. The advantages of the web will naturally outweigh any possible native program advantage.
It's the browser javascript that I would worry about; responsiveness is always a battle.
Besides the confusing fact that you bring HTML5 local storage into the equation for some reason, a local web server doesn't necessarily mean more complex deployment/maintenance than maintaining a .NET application.
Also, pulling numbers out of nowhere isn't going to help your argument.
3 and 5 years are the common life cycle's enterprise IT use when discussing any existing implementation or any new system design. These are not pulled from nowhere.
Oh and as far as I'm concerned "3 to 5 years" is still pulled out of nowhere. You aren't mentioning any sources, just describing a really vague process that you think is "common". If you have a working, flexible system with which you can harness a huge continuous effort in developing the technology behind it for free, you aren't going to kill it off just because your enterprise clock says so.
I started with a small "industrial" computer — Intel D525, 2g RAM, 40g SSD — costing about $300. I installed Ubuntu 12.04 Alternate with X and Fluxbox. I used Chrome for the display. I configured it to log on automatically upon booting, start X, and run a script configured to start Chrome pointed at the proper URL.
Then I used remastersy† to create an installation USB stick. Boot from the stick, and it installs the customized Ubuntu non-interactively. The first time the system boots, it runs a little dialog where you tell it its role in the system (i.e, what view of the overall status should it display).
If you later need to reconfigure it, you can log in over SSH and run scripts to change the configuration. Or, if absolutely necessary, you can visit in person, open the cabinet, and hook up a keyboard.
It spends almost all its life waiting on an XHR, which asks essentially, I'm showing version x, send me the next version when ready. When version x+1 comes along, the server replies to all the XHRs waiting for version x+1 with a chunk of JSON describing version x+1. The displays then all update their DOMs and hang an XHR for the next version.
I later added a separate heartbeat loop. Once a minute, it asks the server if it's alive, and it puts up an out-of-service screen if the server stops responding.
Actually on that note I'm surprised I don't see more community/charitable notices in the mix for digital boards (these could serve as "defaults"). Having non-commercial and regularly changing ads in the mix would actually get me watching, and is potentially even tax-deductible.
The biggest reason for html as the menu format was it would be the best format (in terms of flexibility) to use for the display content and localization. The local db was embedded FirebirdSQL, and connected to a remote Firebird instance running on a central server (transactional data was replicated as connectivity was available, and it wasn't more than half the time)
If I were going for a digital signage solution even two years ago, I would probably lean towards windows. There still aren't tools for developing visual animations that match what Flash (though deprecated) offered. Flash is really easy to embed in a full-screnn app, and offers a lot of flexibility for the purpose. The tooling is broadly available, and setting up a canvas of the right proportions is all you need to start.
Flash costs a lot more than Windows even. IMHO The cost of software licensing is really minimal for most companies for these kinds of things.
Today it would be a tossup of a windows solution with Flash and/or an embedded or otherwise chromeless/fullscreen browser and a linux solution. If I were to guess, the windows solution would probably be done faster. Dealing with multiple displays and orientations in Linux is much more of a PITA, let alone that VS is actually pretty decent.
You wouldn't use localStorage for images.
You know, this is an extremely valid reason
You just write the program (making it go fullscreen), put it on the Startup folder and that's it.
If there was a turnkey solution for other platforms I'm sure this would be very helpful.
And the cost of the windows license is irrelevant if you consider the other signage material (displays, mounts, etc)
I thought we were arguing for something that was more stable than Windows?
Done this a few times. Entire process for a kiosk is:
1. Build a full screen app in Visual Studio with WPF. WPF is great here - 2d, 3d, interactive, animations, video everything, all without any code. This is beyond trivial and the tooling is entirely free.
2. Build it and copy the exe to target windows machine (a cheap AIO desktop - Sony VPC are nice as they have VESA mounts, touch screens and don't break that often)
3. Set the machine to auto login and set the shell to the program.
4. reboot it. Done.
This takes literally minutes.
Doing it this way was probably the easiest way in the mind of the responsible engineer and i am sure it generally works fine.
That MouseJiggler thing is pretty lame though ;)
Sure as hell not the way I'd do it, but for a non-critical system that really just kind of sits there and doesn't cause any problems when it crashes, why not if they only know Windows desktop dev and are only deploying a few? Use what you know.
On one hand it scares companies because they think they can't find Linux people when they need them.
On the other hand the universities are crunching out .NET and Java coders who have no ideological reason to use Linux.
Something that could fill the niche here is open software platforms for digital signage. Because the more user friendly Linux gets, the more I'm seeing of it in Enterprise environments. So if only someone could make the Fedora or Ubuntu of digital signage using open source.
However, I watched the crew on a Virgin America flight announce that we had to "reboot" the plane because the entertainment system was frozen. It was, and everyone could see it -- it was Linux-based (not certain which flavor, pretty sure it was Debian-based though.) It had frozen, and all the screens (one for every seat) had a console stuck in some batch job and displaying the output to the screen. Luckily, we were still on the ground, so the reboot wasn't so bad.
But it was alarming. Reboot a Windows-based advertising display? Who cares. Reboot the plane because the Linux-based system is frozen? Quite a bit more alarming.
Before that, we had a Mac mini in the conference room because we found a nice mount, and now we are just buying TVs and mounting an Apple TV.
We've been running the same system for 6 ish years, sometimes people ask us to put powerpoint or videos on the displays, which would be more difficult if it was a Linux system.
The main problem with the displays is not viruses, but rather pop-ups telling you need to do some update or other (like the one shown in the article).
All the benefits of a managed Windiws installation, and suitable for 99.9% of kiosk requirements. Probably.
Our app is entirely web-based, so it was quite possible to choose any reasonably modern OS.
http://semiaccurate.com/2013/06/13/sapphire-shows-18-screen-...
For real embarassment, nothing beats the unpaid software nag.
Always wondered what the hell, especially since it doesn't even seem to provide stability.