We know SAP needs to do a better job explaining our UI/UX strategy. What we have been saying sounds to me like "we support every UI," but what we really mean is "we will go to the user (and make her more productive)."
If someone is using Excel to create some budget scenarios, he should be able to access SAP data, and update the SAP system with the outcome. If someone is primarily working in Outlook, he should still be alerted if a critical customer order is delayed. When a manager is driving to work and has some dead time, we will let her do some routine tasks by voice. And when a salesperson is in front of a customer, she can find the status of orders, payments, or even book an expert to work with the customer on a new opportunity.
As an IT community, I think we may be a little too obsessed with TCO. Is $2000 a high TCO or a low TCO? Well, if we are talking about something with very little return, then it is high (and if we are talking about a new computer, it might be high, low, or just right). We should be thinking about Return On Total Cost of Ownership (ROTCO), and some of these new solutions (like search, widgets, and Duet) provide VERY high returns on very reasonable TCO.
Thanks for the great, thought-provoking comments!
As an aside, how many runtimes will the user need in the future? A couple of browsers, a widget engine or two, a java and .net runtime and apollo.
I am excited about what this means for users and developers. regards, Nigel
Widget engines are much simpler, offering far fewer capabilities. We have not yet settled on an approach to productize our widgets (although some are already available to SDN members!), and we have not yet settled on a product availability matrix (PAM) -- which widgets on which platforms on which widget engines. I hope we will hear from the community which combinations are important. I suspect to hear that Gadgets on Microsoft Windows Vista will be important, and Dashboard on Macintosh. Perhaps there will also be demand for others, such as Yahoo! Widgets. Let us know!
We have learned, however, that it is relatively easy for a developer to take a widget and port it to a different widget engine. Perhaps a good strategy for us would be to release reference versions of the widgets on one platform and ask the interested portions of the community to port it to other platforms.
Right now, our widget team is developing for multiple widget engines, including those listed above and some additional engines that offer unique and valuable features.
I'm sorry not to give a definite answer to a great challenge, but we simply have not chosen a go-to-market approach yet for widgets.
As to runtimes for the users in the future, there is a potential for a problem if we are not careful. I believe almost everything will come bundled into the operating system, and I hope we can support the most important native stacks, plus one cross-platform (e.g. Java) stack for less popular platforms. Again, we'd like to hear the voice of the community on this topic as well. This is important not only for desktop platforms, but also handheld. For IT shops, this could mean Vista, Mac, some voice environments, Windows Mobile, Blackberry, Java smartphones, "legacy" Windows XP, ... this list could get quite long.
Thanks for another set of great (difficult, but important!) questions.
Which engine are you going to take as reference?You indicate that porting isn't that difficult. That is only true if you stick to the least common determinator and don't use any specific goodies of an engine. I tried the migrate a SDN search engine widget for Dashboard (SDN by the Dashboard light) to Opera(Phantom of the Opera) and in a sense I needed to start all over (even for the graphics).Second problem is the hosting of the widgets. For proper installation, the widgets should be available on a central instance (for eg Opera widget deplyment) instead of being scattered around.
After we release the tools beta for everyone to try on their own, we'll have to see if the level of abstraction is adequate enough for building one widget and deploying everywhere.Regards,Eric
Widgets play an important role in all these aspects. The ability to break a complex process or task into simple steps and provide a view into these simple steps via widgets is very powerful. Gone are the days when one had to visit the stock websites to find the stock quote of individual symbols and then combine. Now it’s available on the desktop for a portfolio of stocks, in a single and simple view, updating almost real-time. Like stock which found permanent abode in most of our desktop, enterprise widgets will follow.
Widgets if designed well can provide a simple yet powerful view into the information (including events, alerts and exceptions). They provide a platform for presentation layer mash-ups, which obviously not only increases the consumption of information but also adds value to the information. These widgets in turn can be loosely coupled to quickly address a specific paint point making them a sound building block for situational apps.
Widgets are nothing new. The concept has been there for long. Development community has always been developing mini apps using different technologies, mostly for its own consumption. Widgets has given these mini apps a new name, made them delightful, standardized (?? to some extent) for use of XML and a scripting languages among others. And they have taken these mini apps from consumption by developers to mass consumption by most end user.
The good thing about Widgets is that they are easy to develop and distribute (deploy). And they are delightful to use. They make complex things simpler. They bring right information to the end users as if they were tailor made for them. It’s about increasing the human consumption of information in a delightful way!
I answered Jason's post separately (please have a look), but wanted to address your additional point as well.
There are lots of jobs where people need to multi-task, keeping an eye on some changing data or status, performing some simple and repetitive tasks, while doing more complex work most of the time. For such users, we think widgets could be a useful tool. For developers, system administrators, and many other technical professionals working with computers, this is exactly the way they work -- respond quickly to a system performance problem, change a few configuration settings, while working on building a new system.
If this type of technology can help you, I would encourage you to do a little exploration. Thanks for the feedback!
The answer is simple: this new technology will improve work and life for many people. If you don't need widgets, you won't be forced to use them. You will only have to adopt widgets if you want to, and if you think they can make a positive difference in your work or life.
Some people do not heavily use e-mail, and for them a device like a Blackberry is not needed. For others (like me), smart phones are so necessary that I carry two with me (Blackberry and Treo)!
Widgets will be useful to people who need to "keep an eye on" volatile data, like server performance, new e-mail messages to multiple accounts, new blog posts, sales orders, or currency exchange rates. Widgets allow you to set up small monitoring tools that watch data values while you go on with other work on the rest of your screen. Yes, there are dedicated client-side applications that do this for some monitoring situations already, but widgets create a consistent framework for doing this task, and allow for innovation and applications on top (like combining everything you're monitoring into one window, setting alert thresholds when something changes too much, and easily sharing such tools with others even in different companies).
Widgets are also helpful to people who have to do several common tasks repetitively, while also doing other work. Without changing your Portal context, you can do a simple task "off to the side," like creating a new user account, resetting a password, bouncing a server, changing an address, approving a purchase requisition, adding feature ideas to your scrum backlog, or keeping track of time spent on a project. Again, any of these could have been built as dedicated client applications, but then it is much harder to share them with others.
In fact, widgets frameworks are like any other virtual machine environment, with some giving a high level of programming abstraction, easy ability to update over the internet or intranet, easy ability to install new applications (and share them with others even in other companies), and a very simple and productive programming model for developers.
In short, if you have to build an application to monitor something or do simple transactions, without disturbing your work in your Portal, and would like to be able to share the work done by others and the work you do, widget frameworks can be a great choice. SAP is helping make this choice available to our customers, because we think it will be a useful new tool for these types of situations.
I hope this clarifies a little. My suggestion as well: try a few widgets (like the NetWeaver monitoring widget) to see if this new technology will be useful to you. It won't take you much effort to try out, and it could be a really great addition to your tool-chest. Thanks for the great question!
I view widgets as productivity tools that can make certain everyday tasks more convenient. What will be interesting in the future is when we see an easy way to bundle certain related widgets together for download and display.
For example, we were thinking of creating a bundle of system monitoring widgets for our BW basis team. There are certain individuals who do hourly checks against multiple transactions to monitor different things such as disk space, system usage, and process chain status. Yes, they do have standard SAP transactions to do all of these tasks, but it would be nice to have a quick high level view to see the overall system status of the BW system.
If you have something available like the Yahoo widget heads up display, your hourly checks can be reduced to a quick keystroke for a one stop view of all your necessary checks. Of course, different users could pick and choose the widgets that they needed to monitor for their own customized BW widget bundle. This would also make it easier for them to hand off 3rd shift support to our operations group. I can just hear them now saying "Here, download this widget bundle, hit Ctrl-F8 every hour, and if you see any red lights, give me a call." Wow, that was quick. 🙂
In the future, I would like to see where you could create a separate heads up display for different widget bundles. That way I could hit Ctrl-F8 for my BW monitoring bundle and maybe Ctrl-XX to view another bundle of related widgets such as your personal news and stocks.
Even with the above example, we are still limiting widgets for our own little world. We should probably be thinking higher level for end user productivity, like a senior management sales monitoring widget bundle. Widgets are another step towards the "thrill your users" that Shai talks about. Until we start thinking outside of the TCO box a little, we cannot take this next step.
So, I look at your bio and scroll through all the really neat work experiences and there it is! Dendrite! Aha! Those were the days, my friends.
Good to know that you weren't seriously harmed by your experience there (i.e. working til 4 in the morning).
- "They Call Me Bruce"
"What is [spoken] 'while(*i++=*j++;;) ;'?" [Answer: strcpy() in C]
Welcome to SDN, home of the ueber-geek! I hope you were reading this blog because you are interested in widgets for the enterprise and are planning to contribute ... 🙂
Enter the destination URL
Or link to existing content