Silverlight User Asistance

[mattbnh]

So the new project team for the new web-based interface for our current product is enraptured with Silverlight.

I'll be going to my first project meeting next week and I would like to walk in feeling that I have got a clue.
So far I don't. My head has been glued to the desk working on convention help, and I haven't had a lot of time to go wandering around trying out new stuff like Silverlight.

So I am doing some research over the weekend to try to find out what user assistance model is intended for Silverlight applications for a real business, not some pop-game or phony travel website.

Haven't found anything that really talks about user assistance yet, so I figured I ask people who make user assistance their business.

So I ask you, does anyone here have a breadcrumb or two that will lead me to something that explains how user assistance fits into a Silverlight application?

Or from a Madcap perspective (since this is the Flare forum), how will Flare help me develop user assistance for our new Silverlight application?

[Andrew]

As I understand things, Silverlight and Flash are fairly similar when it comes to their UI capabilities. I'm no expert in Silverlight, but it seems like you basically have two choices:

1) Invoke something like WebHelp from with the Silverlight UI. This will take the user out of the Silverlight experience and put them into a regular web page (MadCap does not yet have a Silverlight help target that I have seen), with all the benefits and drawbacks of that.
Pros:
- Requires little developer attention; merely passing calls to open HTML files with some parameters.
- Can design and build using an application like Flare to control all aspects of look and feel.
Cons:
- Much more difficult to match look and feel of the Silverlight UI.
- Takes the user out of the "main" UI and into a completely different kind of experience to get help.

2) Build help into the Silverlight UI itself.
Pros:
- User experience an excellent match for the Silverlight application.
- You can design your help to fit specifically the situations it needs to fit (i.e., you can "embed" the help much more effectively to be there exactly when the user needs it, and out of the way when he/she does not).
Cons:
- Requires significantly more developer consideration and must be a part of the UI design itself.
- Not sure how easy content development/editing would go...not sure if you can just display HTML "pages." If so, you could pretty easily author using something like Dreamweaver. If not, you may have to either get ahold of a XAML editing tool (XAML is to Silverlight what HTML is to a web page) -- I think the Microsoft Expression suite has such a tool, but not sure if it's pratical for content development.

Personally, I'm more professionally interested in 2, and I think, if you can get your group to buy into the idea, it would be a more effective way to go (though that could change if there is a decent Silverlight Help standard at some point). Bear in mind I'm no Silverlight expert; just trying to provide a response to a question that's been sitting here a couple of days.

Good luck. Whatever you decide to do, I'm interested to see how it turns out.

[KevinDAmery]

A Silverlight target... if that isn't on the roadmap for Flare, maybe it should be... hmmm....

[LTinker68]

Someone here was asking me if I knew anything about XAML, Silverlight, and Microsoft Expressions. I'd heard vaguely of Silverlight and looked up Microsoft Expressions (sounds like Visual Studio combined with FrontPage), but I hadn't looked up XAML yet. I'll be curious to see how that works.

Good info, Andrew.

[mattbnh]

Thanks folks, especially Andrew, for replying. Our devs also haven't seen anything from MS, except implications that they could put together a custom app to serve up help. I don't think we are going to go there. Time is short - they need to demo at a show in September, so we will probably go with Webhelp for the first version. It is mostly a web port of our main line software, so some of the current help info will be re-usable. After that we are thinking about a help pane or dynamic help arrangement, but we all want to see what kind of support there is in Silverlight, if indeed it doesn't prove to be another MS distraction.

Maybe I am missing something but it seems like one piece of the business MS is shrinking away from is user assistance, as in they are building what they want and think is best, but they are no longer interested in taking responsibility for creating a mechanism or a standard. They must see no upside - just complaints and more security holes. So they are not releasing anything to the general public, keeping help2 and beyond as a private sandbox (or sandcastle perhaps).

I wonder if that opens the way for one of the vendors to create a killer help app - one that doesn't ape some 20 year old format or a knockoff version of the latest MS assistance. Personally I think Madcap has put a lot of the picture together on the HAT side. Now if someone would only come up with the front end that solves Help for users and writers. As a famous actress once said, "I can dream, can't I?"

[RamonS]

Unrelated to the help aspect, any word why the developers decided to use SIlverlight? I am surprised how many companies jump on Silverlight although it is unproven technology that is neither cross-browser nor cross-platform compatible. In a day and age where Linux and Mac desktops are not rare exceptions anymore it just strikes me as a very risky choice. Is it just again that the Silverlight development environment makes it easy for the developer and compatibility, portability, quality and supportability are again mere afterthoughts? It might be less of an issue if the audience is surely MS only shops that chose to use IE and already deployed Silverlight across the board. Any deviation from that strikes me as a sure path to trouble.

[mattbnh]

Hi Ramon

I will ask the developers but I have some ideas why:
- They can leverage code and objects already written in the c# clients and server
- They can separate some of the UI design work from the back end coding
- Silverlight is advertised as cross-browser. Has any MS software ever fallen short of initial claims?
- original product only runs on XP/2003 Server. ANY browser beyond IE is bonus but uneeded presently
- client uses .net webservice
- buckaroo factor - young engineers anxious to stay on the cutting edge

[KevinDAmery]

Plus should be fairly easy to integrate into a product that's developed using WPF and .NET.

[Andrew]

Don't mind RamonS, mattbnh. He takes personal offense anytime someone uses a Microsoft product.

[KevinDAmery]

Don't mind RamonS, mattbnh. He takes personal offense anytime someone uses a Microsoft product.

My theory is Steve Ballmer owes him money

[RamonS]

Well, I looked this weekend at the Microsoft project for the public telescope project. Nice idea, but it appears to use Silverlight. It is slow, choppy display, and no fun to use. Also, in all the arguments that were listed pro Silervlight not a single argument was about how the end-user benefits from it. It was all about how the developers have an easier job. Screw the developers! They get paid boat loads of cash to do their job and still produce software that lacks usability and is not intuitive. But they could do that in half the time. Horray! We are all happy now!
Just to set the record straight, I do use Microsoft products and some of them matured nicely into something that generally works. But stuff like Silverlight is half-baked stuff from the "we have to have that too" pile. Same like XPS and OOXML. Just more incompatible, single-vendor junk that the world doesn't need. How does any of that benefit the end-user? I just don't see that. What is more likely to happen is that end-user needs yet another blocker add-on to get rid of all the Silverlight based advertisement.

[wijnand]

XAML is a "language" that you can use in Visual Studio 2008 to create your interface with. Instead of having the forms stored in your C# code you have a seperate XAML file that basically explains to the compiler how your dialogs should look like its very open and clear. I am currently using it to develop an application

Here is an small example:

<Window x:Class="WpfApplication1.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006 ... esentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300">
<Grid>
<RadioButton Height="16" Margin="109,80,49,0" Name="radioButton1" VerticalAlignment="Top">RadioButton</RadioButton>
<Button Height="23" HorizontalAlignment="Right" Margin="0,0,49,24" Name="button1" VerticalAlignment="Bottom" Width="75">Button</Button>
</Grid>
</Window>

Basically the reason why programmers like XAML is because it disconnects the "Visuals" with the actual code resulting in cleaner and more managable code.

[LTinker68]

Basically the reason why programmers like XAML is because it disconnects the "Visuals" with the actual code resulting in cleaner and more managable code.

Which means they can probably leverage the same programming code for different outputs, like a desktop monitor versus a PDA/iPhone, etc. Right?

[RamonS]

That can be done many ways and without XAML, although I see the benefit in it for the developers. But again, where is the benefit to the end-user? And where is the cross-platform compatibility? The great danger with XAML is that Micrsoft will use it to replace XHTML and CSS or at least spread it so much as to be disruptive.
Any development environment is just a means to produce a product. Agreed, some are better suited than others, which is why .NET apps often fail blatantly in the business world compared to the COBOL mainfraime apps they are supposed to replace.
And yes, Steve Ballmer owes me money, as he and his company does to many of us. Just add up all the downtime and resources wasted for applying patches and finding things not to work as advertised. If the model would be that Microsoft had to compensate every user for their downtime so that yet another needless reboot can be performed, we either get rich or we get much better products out of Microsoft. My issue with most of the Microsoft stuff is that it is broken right out of the box and that after paying dearly for it.
Also, any ASP.NET based web apps mandate that one uses IIS. Not only is IIS a horrible piece of crapware, it yet again is not cross-platform capable and needlessly expensive. One can run a web server on a Linux box for a fraction of the cost and with the same if not higher reliability.
When it comes to web applications three things in my opinion have to be guaranteed:
- cross-platform compatibility
- cross-browser compatibility
- adherence to common and open, internationally accepted standards
plus the goal that is valid for any application
- create a solution that generates the biggest benefit for the end-user using the least amount of end-user resources
If that can be achieved with a new tool that makes the developers' work easier, then go for it. I just don't see that Silverlight and XAML do that. In fact, they don't even fulfill one of the requirements. The goal in sw development is to make the user happy, not the developer. Developers overwhelmingly don't use the software they create, so why are they the ones who claim the right to say how stuff gets done? I just don't get that. Those rights are reserved for the end-users and within an organization the end-users are represented by support.
And besides that, as a developer I'd settle for something where not one single entity can pull the plug....as Microsoft did once before with VB6, by far the most popular development platform.

[KevinDAmery]

One key advantage of things like XAML and .NET is that developing in them is quicker. This helps end users because the development team can issue new versions, fixes, what have you in a much shorter time. (Many of us have commented about how quickly Madcap can get fixes out to us when they set their mind to it--that wouldn't happen as quickly if they were in a more rigid / time consuming development environment.)

To put it another way, we could develop our help systems in a text editor and handle all of the linking and dynamic stuff like drop downs and glossaries manually. If we were really diligent, our end users would get the same documentation at the end. So our using Flare instead of a text editor technically doesn't benefit our users at all... right? </tongue-in-cheek>

[RamonS]

Ya,ya, I didn't say one should not use any tools, but do so when there is a clear benefit compared to what one has before and compared to viable alternatives. Efficiency in software or documentation development is not so much a tool issue, but one of how organized one performs a project. Just because one can use XAML and .NET to deploy apps quicker doesn't mean that they are better and easier to maintain. I've seen plenty of horrible VB.NET code that even experienced developers could not make sense of. But following your argument that isn't a factor since the original developer used the latest whizbang tool to do something. If that would be the case, why hire CS majors? Just grab some dudes off the street, give them .NET and get the same result for a fraction of the cost.

[KevinDAmery]

I'm thinking more in terms of a professional using a fast tool will get you results faster than the same professional using minimal / slow tools.

Yes, getting high quality results is important--but so is meeting deadlines.