An interesting question indeed.
UX is UX
As far as the process is concerned, it is nearly identical - figuring out user needs, task models, user testing and so on are all similar, if not identical.
The only place where differences exist is in the design process, where certain considerations have to be accounted for.
These are the ones I can think of right now:
- Browsers - web application run on a browser, which means:
- There's a back button to consider.
- You may notice in user testing that users use the 'open in new tab' feature, and this is integral part of their usage.
- Some keyboard shortcuts are reserved to the browser (although a web app can override these - I love the fact that command-S saves my blog entry with Ghost).
- Display size - it is safe to assume a large display size for desktop apps, where web apps may run on a really small screen.
- Platform guidelines adherence - a controversial one, but generally speaking desktop applications are expected to adhere to the platform guidelines more than web apps (in a way, web app are for all platforms, and I'm yet to meet a UX designer that submits variations of design per platform).
- Immediate feedback - Many web apps suffer from lack of immediate feedback due to the time it take requests to get a server response (possibly due to slow internet connection, like when out and about). This is hardly ever an issue with desktop app - to be completed a user action doesn't have to travel through the air (wifi) and then half way across the world and back.
- Different 'UI' approaches
- This is somewhat of a gross generalisation, but with desktop apps one normally thinks of the viewport (the visible window rectangle) as the space available, whereas with web apps the tendency is to utilise a vertically-scrollable document. If this seems to contradict the way desktop word processor work, in fact they do not actually render anything outside the viewport, whereas on this web page, content above and below the viewport actually exists in the document.
- Perhaps most notably, static top toolbars are common on desktop applications because the programmer can just drop them on the canvas and decide which part of the screen will be scrollable. But the document of a webpage resizes itself based on its content (and scrolls on overflow by default) and technological limitations and the HTML rendering engine (rather than canvas on desktop) mean that static element on the screen are still somewhat of a hack.
- Without getting into too much details, layouts of a desktop app are manually crafted by the developer, whereas layouts on web applications are often automatic.
- With all this being said, with a bit of extra effort, a developer can make a web application behave just like a desktop one, and vice versa.
Put your money on web technologies
Not tightly related to your question, but I have to state my belief:
All future applications will be 'web' applications.
This not to say that we won't have desktop applications - but they will simply be written using web technologies, even if used without an internet connection. Reasons:
- If you've been using the NodeJS technology, it puts in serious doubt the feasibility of going through the hassle of writing a desktop applications (ie, compiled applications). Although Google is pushing things in the completely opposite direction, had they wished they could have easily wrapped NodeJS (server side) + client code into a cross-platform compiled executable.
- There are already project out there doing just this - compiling web apps into desktop apps. Perhaps worth noting that Apple's Xcode has already got a webkit component that allows a pure client-side web app to ran as a desktop app (it's a bit of work to mimic the server side).
- As soon as the canvas of HTML5 gets its own Graphical Editing Framework, developers would have little reasons to opt for desktop applications (in essence, the canvas of HTML5 brings desktop architecture into the web, but the latter has the extra of HTML/CSS power).
In addition, Google is pushing towards web-apps world. Although currently we're looking at 'performance-light' applications (say no heavy image processing, like with film applications), NodeJS bridges that gap, allowing taking full advantage of the machine power - your client side is only the interface.