Rich desktop application vs. rich web interface
The openPETRA developers at OM believe that there is real value in having a fully-blown desktop application as opposed to a rich web interface.
Listed below are our considerations. They don't need to dictate where openPETRA will need to go in the future, but that is what we hold true for the OM implementation of openPETRA.
Feel free to enter in a discussion about our stance, to prove us wrong, to show us an inexpensive and non-complicated open source rich web interface framework that doesn't need highly skilled software engineers to make it work well, that creates web applications that are fast to use and highly usable, that works well with .NET, and to teach us a thing or two by doing so ;-)
Performance Considerations
Firstly, when it comes to performance, a desktop application is better responding to the user's commands because no pages need to be rendered and no JavaScript is needed to be interpreted. There is also no lag to the users's click reaching the web server either, which just makes the application more responsive and 'snappy' in general. That might seem picky, but when opening a screen a few hundred times a day (let's say, a complex screen like Gift Entry), it really matters to the user!
Usability and Complex Screen Layouts
Although AJAX and other frameworks have pushed on what GUIs can be delivered in a web browser in recent years, the usability and performance of complex GUI scenarios is usually still better with a desktop application - at least it is easier achieved. Petra has plenty of complex screens, which is not due to bad design, but due to the power of the application and what users want to do with it, and so openPETRA will have those complex screens as well.
Cost and (Ongoing) Effort
We know that very good rich web interfaces can be done - Google and others have shown that. What needs to be considered, though, is whether your organisation has the experienced staff now and in the future, and the money, to realise such slick and powerful web interfaces, and whether you are prepared to ensure it continues to runs flawlessly on the newest, safest web browsers - for years to come!
Integration With Other Software
When it comes to tight integration with existing software on users' computers, a desktop application is well prepared to connect by any means available on that platform - on Windows that is for instance COM/COM+, OLE, ODBC, direct DLL or EXE calls, and plug-in architectures of various forms (e.g. for MS Office/MS Outlook). A web application has simply not got those advantages, unless it uses platform-proprietary technology (e.g. MS ActiveX Controls) to realise custom solutions, and those have their restrictions.
Integration With Your Existing Mission-critical Solution(s)
Bear in mind that most organisations will have one or several existing applications that they use in their offices apart from the MS Office toolset. The tighter they want those applications to be integrated with openPETRA, the more likely it is that such platform-specific means of hooking those applications up directly (as opposed to simple file import and export) are needed.
Why OM Isn't Considering Rich Web Interfaces (at the Moment)
A rich web interface for openPETRA is not needed in OM at the present time. For this reason rich web interfaces are just not OM's focus and that is the reason OM don't assign developers to realise them for openPETRA.
"But What About Our Organisations' Need For a Browser-based Application?"
If your organisation is really sure that they need a browser-based application and want to explore that option with openPETRA further, then go for it! We are prepared to help you (to the extent we can justify).
To get somebody like your organisation started, OM have created a prototype of a web application that connects to the openPETRA server, just to prove that it should be possible to create a web interface for openPETRA. See Prototype of an openPETRA web application for an overview.