I am creating a native iOS App for a .NET based financial ERP. As a lot of business rules have been written in this system so I would like to keep a single code base and build an app with light front end. Key considerations:
1. Light weight front end, all business logic in back end
2. Extremely user friendly UI
Note that application screens are extremely complex with multiple tabs, Tabs within tabs, navigation on left and right side.
I believe these screens will require significant rework. But my challenge is that users are expected to toggle frequently between desktop and iPAD so they should not get lost.
So I am grappling with these 2 main challenges. Has anyone here solved for this? I need some high level guidance before we proceed.
Thanks,
Sandeep
You need to check out www.xamarin.com they allow you to re-use your c# .Net code on iOS. Your back end code could be rewritten and shared between iPad and desktop. You maybe able to share more with some clever code.
I am currently working on an ASP.NET MVC webshop that must be optimized for mobile devices, especially tablets and smartphones. This is for our client at work, but I am doing a little research on ASP.NET MVC Device Detection at home. I created a little application with it and it seems to work just fine. I love the way that everything is separated nicely by using different views for every device type.
The thing I am struggling with now, is wheter to use the ASP.NET MVC Device Detection for that webshop too, or use a client-side responsive framework, like Bootstrap. I am struggling with that decision, because the ASP.NET MVC Device Detection doesn't seem really "grown-up" to me. There is not much to find about it on the internet and it only supports mobile views by default, no tablet views or anything else.
The other reason why I'm hesitating about Device Detection is because the standard ASP.NET MVC library with mobile device user agent strings is probably not going to be updated, so when new devices come out (and they do), the webshop is showing the desktop view, while we have a nice optimized view for mobile devices. Of course there are services for up-to-date device detection, like 51Degrees.mobile, but they are very expensive. (the free version has no support for detecting tablets)
I've found a way to create different views for tablets by using the example in this post, but that example uses a regex to detect smartphones and tablets, which is of course going to be outdated at some time as well.
On the other hand we have the client-side responsive solution (Bootstrap). The disadvantage of a client side responsive site is that the diffent viewmodes are not seperated. The HTML is not optimized for the device. The website is just kind of "throwing in" the desktop version and the browser adjusts the HTML page using the CSS media queries. The code is not as clean as it is with the Device Detection solution.
The quick question: is there any free or less expensive way to use the ASP.NET MVC Device Detection? Is it going to fit our needs over time? Will it not be outdated at some point?
I would really appreciate to hear what you think is the best choice in this case. Thanks in advance.
The entire point of responsive design is that it is device-independent. Device detection in MVC, as far as I remember, began with some rather old IIS Browsercap technology that is quite out of date.
There are far too many form factors out there to keep up with now that Android phones range in size from four to 6.5 inches and beyond. Going with a responsive design framework such as Bootstrap will allow you to target resolutions, not devices. The majority of modern smartphones and mobile browsers (even IE!) will render a responsive design consistently.
You should be using device detection with responsive design. The fact that the browser is under X pixels wide does not mean the user is on a mobile device or that they prefer to see a mobile version of the site.
Using both detection methods allows you to give the user more options and more precisely offer the best experience.
ismobiledevice ships with .net and is available freely to your asp.net mvc app.
http://msdn.microsoft.com/en-us/library/system.web.configuration.httpcapabilitiesbase.ismobiledevice(v=vs.110).aspx
What is the right way to design the page structure of a WebWorks app? I'm using jQuery-mobile as well.
A: Should all the pages be in a single HTML, each page being a:
<div data-role="page">...</div>
B: Should pages be separated in different HTML files linking to each other?
I am currently using approach A, but the app is a slow when transitioning from a page to another. I suspect one of the reasons is the size of the single HTML that includes all pages.
Also another issue I'm having is that pressing the physical "back" button on the phone exits the app which is another reason I'm doubting my approach in having all pages in one HTML.
A very opinionated answer: You're using the wrong framework. jQuery Mobile is extremely bloated and I've seen it perform poorly even on recent iOS devices, not to mention BlackBerry's not exactly very performant OS.
If you continue to go down the jQuery Mobile route, I would still recommend you have all your pages in a single HTML file, not least because the user experience on WebWorks is a bit sub-par when moving between separate HTML pages. For example, you'll get very noticeable "white flashes" when you follow a link to a different HTML file, especially on older/less powerful devices (although you can mitigate that a bit by setting a background colour for your rim:loadingScreen element in the config.xml). It's up to you to decide whether that is better or worse than the slow transitions in jQuery Mobile.
As for the back button, you can override the default behaviour by attaching an event handler to the back key like so (don't forget to have the blackberry.system.event feature enabled in your config.xml):
blackberry.system.event.onHardwareKey(blackberry.system.event.KEY_BACK, function() {
// Back key pressed, go back to previous screen
}
If you're still open to an alternative solution though, I highly recommend you give bbUI.js a try (https://github.com/tneil/bbUI.js) - it's a semi-official framework that looks a lot more at home on the BB than jQuery Mobile and is better optimised for the platform (e.g. allowing you to only load scripts that you need for the particular page you're showing at that very moment, working around some WebWorks/BB-specific issues, etc.) - combine it with Zepto (http://zeptojs.com/) which is a blazingly fast jQuery replacement and you'll end up with an app that is significantly less sluggish than a jQuery Mobile based one.
You can use which ever way suits your project best. For a large app, it's probably worth having a single "index.html" which then links off to several other pages. Can make editing your code easier as well.
Designing a web application with ASP.NET MVC I asked myself how can I also please those people using a smart phone, ipad, etc.. (everything thats touchable...) and not only a desktop/notebook with a browser.
How can I develop a better user experience.
I would be pleased to hear about technical advises concerning the asp.net mvc framework so I can later implement your suggestions concretely.
There are a few levels of friendlyness. You can start with the basic "does this site render well enough to be usable in a mobile browser?" This really should not be a problem for anything new that is using modern web standards but older sites could have problems. Corallary to this is "is my site a bandwidth hog that takes forever to render over 3g because each page is 14mb of animated GIFs and spaghetti HTML?" Or "does my site make mobile devices melt due to aggresive scripts?" Luckily this set is pretty easy to deal with -- modern websites tend to handle this pretty well by default.
The second level is "does this site do anything maddening from a touch perspective." The big thing that can clip you here is hover based menus -- there is no hover on a touch UI. The other common issue is using small links or buttons that one can't hit at least without zooming in to crazy levels. The solution here is testing -- some issues are obvious to all but you won't see some things until you are interacting without a mouse.
The final level is using a touch UI for fun and profit. If you make it this far, you are doing better than many web publishers in this day and age. What is involved here is using touch-friendly UI tools, such as jquery mobile, to handle swipe events and other touch features to make things work more like one expects with a touch UI. An easy example would be making an image carousel swipe-able rather than having to wait for the buttons.
Make the interface chunky - big icons are easy to click, text is very difficult to touch accurately. Set a minimum size for every element, at the very least as big as the individual keys on an iPhone/android's virtual keyboard and preferably much larger.
Ensure that the most relevant options are near the top, and after that the aim is simply to make it intuitive. Fewer menus are generally better.
Go through my tutorial ASP.NET MVC 4 Mobile Features
create mobile-specific views.
-use the HTML5 viewport attribute and adaptive rendering to improve display on mobile devices.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Stackoverflow User Luke wrote in this answer:
The boundaries between desktop and web
applications have really blurred.
Whilst once upon a time the nature of
developing for the web was totally
different to developing for the
desktop, nowadays you find the same
concepts [...] cropping up in both.
Since I am continually looking to improve my existing web applications, I'd like to know which common features of "classic" desktop applications do most web application miss?
For example, most desktop apps prompt the user to save unsaved data leaving a page or closing a window - a feature that many web applications miss. It could be that some feature aren't even necessary or are compensated in some other way. Maybe there are features which can't be implemented in (a classic) web application?
The thing you'll never be able to imitate in a web application is the low latency and instant feedback of a well written desktop app.
Even with the ajax techniques to load only parts of the pages, there usually is a noticeable delay in the response (or maybe it's just me and my narrowband). You're (for at least a few more years) just bound to the orders of magnitude of speed difference between network access and no network access.
The Undo button.
Right-click application-specific pop-up menus is the thing I've noticed most.
Usually right-clicking on a browser application will bring up the browser pop-up menu rather than an application-specific menu.
Keyboard support on most web applications is weak to non-existent. This is getting better than it used to be but you will still find plenty of mainstream sites that can't even get the tab order to work correctly. Most sites don't handle focus correctly and force users to use the mouse to activate even the simplest of data entry forms. You can usually forget about accelerator key support.
You can't pull the plug when the application hangs. (Yes, I'm serious)
For fairness is to mention, that desktop-applications miss a common feature of webapps: XSS (Cross-Site-Scripting). ;-)
Support for Big Files.
Integration with the client OS.
Support for special Input/Ouput Devices.
3D or anything else computationally intensive (specific to each users).
Advanced graphics: I've written a C program that draws a surface joining Bézier patches in a simple window and I had to tweak it in unimaginable ways to get it to draw in a decent time. I can't imagine that being ported to the web.
I mean, doing advanced graphics is not what every application needs, but if displaying nontrivial pictures is slow, then we shouldn't even talk about animations.
One Proper Macintosh menu bar support.
If you're a long-term Mac user, even with two large monitors, you have muscles that swoop to the top of the screen for actions, comfortable in the knowledge that the infinite depth effect will kick in and you can slide along that edge, picking from the menus.
No in-browser app can deliver that experience.
Two Command-keys, which is a side-effect of the menu bar not belonging to the app but goes a bit beyond that - good desktop apps have command-key shortcuts (accelerators to you Windows guys, I'm not just talking the Mnemonics which work with alt-key support). Great desktop apps show little reminders next to the buttons that have accelerators, when you hold down the appropriate modifier keys and wait a fraction of a second.
Three Smarter tables. There are a lot of apps where some kind of spreadsheet view works as a paradigm, including editing, sorting, resizing columns. I think I've seen some odd examples of partial support but a good table in a web app is still a bit of a dancing bear.
Four Used to be right-clicking but I'm finding more and more apps that do this properly, like Kerio's excellent webmail engine. It is still missing in enough web apps to be worth emphasizing.
Displaying application request/process status or messages on Taskbar or Status bar.
For the web, Javascript can be used to update text on status bar, but its not a common usage.
The usability benefits of standard GUI elements that look and behave uniformly across applications.
(Although this will surely change as web app developers adopt certain GUI elements and patterns that are considered best-practice, notably by eventually using the same libraries, e.g. for drag-and-drop.)
A common feature of "classic" desktop applications is the ability to work without an internet connection. I miss that in Web applications.
For example, MS word works without an internet connection, but you need to be connected if you want to use Google docs.
Of course, it does not matter if the application requires an internet connection anyway. For example, if its a feed reader, I have to connect to the internet, whether I use a desktop reader or an online reader.
Drag and drop from Finder/Explorer into the web app. And vice-versa.
The ComboBox is the most notable widget omission.
On the web, lack of desktop features such as popup dialogues is actually a boon, making for a simpler interaction experience. Think also of the autosave draft feature of Gmail vs. the desktop convention of prompting the user to save.
So consider carefully before trying to reconstruct that desktop feature in your web app.
Decent help. Seems to always be an afterthought, if it's even implemented...
Desktop integration (may change if we get online desktops)
Offline use (does exist but it is early days)
(Reliable) Responsiveness
Reliability generally (somewhat debatable as there are pros and cons - e.g. your data is probably better backed up online, however security generally is less in your control with an online app, and if the network connection fails an online app tends to freeze or fail horribly.)
Blue Screen of Death
A task-specific UI with no extra controls. A web app, in addition to all the controls of the web app, also has back, next, bookmarks, etc buttons. You end up with an extra inch-high set of buttons that don't directly support the task at hand.
This isn't necessarily a programming feature, but the audience of an application will be different. For a web application you are cutting out a complete segment of your audience (those with slow or no internet access). While this is a relatively low number, it is a difference between a desktop application and a web application.