Now this maybe a little left field, but I have been talking to some EPOS people who have been asking if we can expect EPOS systems delivered in Silverlight. Funny enough, I have also seen people searching my own blog on this subject…
So what is the chances? To my knowledge there isn’t anyone attempting this, and there are a number of reasons why not. I have to say the chances of getting a Silverlight EPOS system are at best, very slim.
Why not?
Many EPOS systems (especially the entry level solutions) are built to work and run a physical till (cash draw and receipt printer). EPOS systems are often a single install, with your back office staff basically having the same software installed that will drive your front office point of sale terminal (till). To drive a POS terminal, the software has to interact with drivers that are actually installed on the physical machine.
Silverlight in essence is a web based technology, and as such cannot interact with drivers etc on the host PC. This is purely due to security. If you are not technical and reading this, just think, if a website could easily take control of programs and drivers on your PC, what sort of damage could a malicious hacker / developer do?
Wait, don’t get turned off just yet…
Though Silverlight couldn’t be used to drive a POS terminal, .NET applications built using WPF could, and these look and feel just like Silverlight applications. I know this means a client installation (which Silverlight avoids) however, on the POS you have to have a number of drivers and applications installed in any case.
Don’t think though that you have to use traditional thick client applications for your back office staff. Though most EPOS systems use the same software for front and back office (especially smaller solutions) it doesn’t mean this has to be the case. A division of my own company, workFile EPOS, delivers a thick client POS application, written in .NET, but back office users use the system delivered through a browser (thin client), removing any requirements for installations in the back office or indeed (if required) machines at home for home use.
EPOS systems that split front and back office functions can easily provide more flexibility, in terms of both user experiences administration flexibility. At workFile EPOS we have been looking to replace a number of web pages with pages using Silverlight to deliver a richer experience. The thin client sales agent is a prime example, delivering a “sales” interface without the need to drive a till or any hardware.
Silverlight EPOS is go…
In conclusion, yeap you can have a Silverlight EPOS solution. The chances of you seeing one shortly though are slim, and there is no chance of you using Silverlight to deliver a POS terminal. Also think that many EPOS systems were written many many moons ago and still don’t really take advantage of thin client technology or in some cases newer versions of Windows (I have seen many that still run on DOS!)
But, all this being said, some EPOS providers out there, like workFile EPOS, have the potential to use Silverlight to deliver EPOS back office functions, which bring together all the benefits of EPOS with those of rich end user experiences. If the demand is out there, no doubt Silverlight will be used for back office EPOS systems and WPF for the POS terminal experience. We shall see…
Andrew Smith CTO 
[…] silverlight epos? […]
I know it’s still early, but have you tried to see what you can do using SL4? It will allow you to get out of the browser sandbox, but I don’t know what you can do from there as far as hardware peripherals.
HI
As yet we havent played that much with SL4. However, SL4 applications will run in either the sandbox or as “trusted” applications. I see the “trusted” applications more for business, and sandbox side of things for the web in general. We know that SL4 in the sandbox will support use of the following:
access to webcam, microphone and printers
HTML within your applications
offline DRM support
control over aspects of the UI
However, for “trusted applications” SL4 will allow the following:
Read write persmissions for the “My” folders, such as “My Documents, My Videos” etc (or similar folders on other OS)
Interaction with other applications, e.g Outlook allowing the application to trigger outlook to send an email
COM automation (which may allow us to control periherals such as a POS till) via COM components or .NET???
There are also new interfaces in place for trusted applications that allow the escalation of security such as group policy objects. Also there are full screen enhancements and support for the keyboard along with networking enhancements which mean cross domain access without the need for a cross domain policy file…
So you are right, SL4 may well allow EPOS systems to deliver a POS component within Silverlight. If so, I can see the potential for a new wave of EPOS solutions popping up using SL4. workFile EPOS may well be due an upgrade if this is the case… http://www.workFileEPOS.com
At my company, we are about to build a POS to be ready for summer. I doubt I can convince people here to use SL4 yet, but we will likely build all of the logic using WCF, so the UI could be switched out more easily in the future. If we do any investigation of SL4 though, I’ll try to let you know what we find. Thanks for the response.
I have seen how to interact with COM etc with SL4 and there are real posibilities that driving till draws, receipt printers etc could be done, however I am not 100% sure on that. If you want that “look and feel”, have you guys thought about WPF for the POS? The only advantage I see of delivering such an app in SL4 is the slightly easier management of the application (regarding installation, updates to the appliation) and being able to use SL4 on multiple OS platforms…
I guess it also depends on your architecture of the system and how you see a business using your POS. If its a traditional everything on one box type installation (back end and front end features) then WPF really would seem like the right choice. If however you guys are splitting front and back office, then SL3 for the back office and WPF for the actual POS seems an ideal match…If you are using WCF then you are already well on the way to that scenario….
Good luck….Keep me posted…
We are still in the initial discussions internally about what to use, but WPF is looking strong. Given that it would have to also be a disconnected application (if the store’s internet goes down, they still have to at least be able to do a subset), we are looking at the Sync Framework as well in some manner. I’m not sure SL4 is going to buy much us, but our marketing department is big on being able to say our software doesn’t have to be installed. If we go SL4, I’ll let you know if it was worth it. 🙂
If you have not yet looked at the Silverlight 4 beta I suggest you do, along with MEF
I have been using Silverlight 4 beta and I strongly believe there is a now a good possibility of using Silverlight to deliver a POS. In addition, using MEF (managed extensible framework) you could build a POS that is independent of your hardware implementations – and have these plugged in dynamically at run time based on configuration / found components…
Our proof-of-concept SL4 POS is done. We had to create a .net component that can be created through COM (in turn, creatable from SL4), which wraps the specific POS for .Net functionality we need. It’s not pretty, but it works. It lets us support any hardware that is OPOS/UPOS. It of course requires an initial install of POS for .Net (if not installed) and our wrapper component…not to mention .net framework if not installed. I wish they had a Silverlight version of POS for .Net, since SL4 can create COM components now. I won’t go into why SL was chosen by our management, but I would recommend WPF instead to anyone else for now, as it would eliminate some headaches, and is much more flexible. Later…
Interesting, sounds a little fiddly though doesnt it.
I personally would agree with you, for an actual POS use WPF or something that is designed to run on the client only. For back end EPOS functionality, fine use SL4 for example.
Hi Michael,
I’m trying to do just what u have accomplished. I am at the early stages and already running into issues with the POS for .Net events not synchronising with my main thread. Did run into this and how did u manage to get around it?
Cheers,
Darren.
All I can suggest is that you check the COM marshalling objects. Always take control of the initialisation of the objects and then the disposal of all objects and ensure you marshall them out of memory (especially COM based objects which are what POS objects typically are)
good luck
EPoS Systems, provide a fast and efficient way of dealing with customers. They handle the calculations involved in sales (totals and change), issue receipts – these have historically been the main function of normal tills. EPoS systems, do this and a lot more. They can integrate directly with credit card payment systems, keep track of stock levels and of course keep track of customer information.
Nice blog.. epos software I would like to thank you for the efforts you have made in writing this interesting and knowledgeable post.