QUESTION Is there a way to detect if a visitor is using the NoSquint extension for Firefox?
BACKGROUND:
I have a games site where all the game web apps scale to fit the window, which enables the user to determine how big the app appears. NoSquint provides a similar feature to enlarge sites to make them easier to read. But this conflicts with our built-in autoscale feature and causes the page to become too large to fit the window. If the user understood what is happening, the user could tell NoSquint not to scale a particular website. Unfortunately, people don't understand what is going on and it results in support emails. If I can detect the existence of the extension, I can deactivate our autoscaler.
Related
I've created an app in Rails which can be put on the homescreen of an iPhone. With some javascript hacking, I can make sure all internal requests stay within that frame. While this works, there are also some drawbacks. With the rise of PWA, I was wondering whether that would be a good alternative, so my questions:
Isn't PWA overkill if my only requirement is that the app is instalable?
Do I need to install all the service workers to get the PWA installable?
Is there some alternative I might have overlooked?
To answer your questions:
From google's PWA site:
Progressive Web Apps are user experiences that have the reach of the web, and are:
Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
Engaging - Feel like a natural app on the device, with an immersive user experience.
This new level of quality allows Progressive Web Apps to earn a place on the user's home screen.
So my answer for your first question is, no. It's not overkill, it's exactly for that (and more, but you don't have to implement all the available features).
If you want the user to feel like the user is on a native app, yes you have to. There are a lot of basic service workers and builder to use that enable basic caching already.
Here is a checklist from google on what you need to have a "proper" PWA.
Microsoft suggests this site to get you started for basic modern websites.
Except for using something like Cordova, I don't see any alternative for PWA's that suite your use case, the only alternative I see is leave it as it is, if you don't need a PWA. The hype is currently high and you should definitley check it out. But as always, you don't have to if your product works as it should.
There seems to be a lot of conflicting information out there. It might be that support has increased recently, or changes to adobe.com/air have made some information difficult to find - but I can't track down a definitive list of things to avoid.
I know that actionscript won't run in loaded SWFs, I know that some people say that filters and blendmodes and halo components won't work. I've also read many posts saying they will (at least that blendmodes will, and that halo will run, but slowly so still use spark)
I have a large amount of AS3 code to plan for upgrading to work on iOS, but at the moment I have no idea what things will break (or what things will break when those things have been fixed!)
Is there a list of unsupported APIs, or iOS dos and don'ts?
Thanks
:S
First, yes. Externally loaded SWF's will not run. You can however embed SWF's/SWC's into your project and include them inside of your package.
As far as Flex components, stay away from Halo. You should use Flex 4.6 and stick to components with mobile skins. I recommend downloading Tour de Flex http://www.adobe.com/devnet/flex/tourdeflex.html to get an idea of whats available.
As far as blend modes go, I'm not really sure. I haven't used them in mobile yet. However filters are supported but they are expensive. For drop shadows on rectangles there is something called RectangularDropShadow. This is actually a component and therefor less expensive. However it can only be used on rectangular groups.
You should have access all of the AIR API's. You will however be restricted when using some of File related classes since I don't believe you can leave your Appliaction Storage Directory.
One big performance tip I can give is to use AS3 over MXML whenever possible, ESPECIALLY when creating item renderers. Use BitmapImage over Image whenever possible, again especially in item renderers. Use cacheAsBitmap whenever you have images that don't change often. And stay away from any Flex component that doesn't have a mobile skin.
You may also want to read up on View and destruction policies.
http://www.adobe.com/devnet/flex/articles/flex-mobile-development-tips-tricks-pt1.html
This link also has some more performance tips
http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-checklist.html
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.
I'm working on the requirements & specifications for a new iOS app intended for use by certain professionals working "in the field". All day long for weeks on end, these folks have a sizable reporting burden to their superiors using standardized forms that track all different kinds of information. Traditionally, those forms are in PDF, and are simply printed and filled out in ink and then shared with the dozens to hundreds of others working the same operation. Sometimes they'll use a PDF with form fields so the data can be typed and then printed as part of the form. Either way, given their workflow, time and stress pressures, and other factors, it's not a very productive way to get the standardized reporting forms done.
The app we're spec'ing would offer an iOS (and Android, if possible -- but secondary or even tertiary requirement at this point) user interface for tracking the data they enter in the field, organizing it in a logical manner for each individual user, and with the press of a button, take all that data and automatically create a PDF file of it using the standardized form.
Of course, the forms are STRICTLY and rigidly standardized in this industry, and any deviation in format, structure, or presentation is simply not tolerable.
So I was approaching the project by thinking the app would maintain an internal repository of the original standardized forms from the accrediting organization, with each possible data area defined as a field. The app would:
open the necessary PDF form for the task at hand;
parse its dictionary to identity the specific data fields;
for every single field, identify the relevant data from the iOS app's own user interface and data tables, and assign that data to the corresponding field from the PDF/dictionary
export the PDF to a NEW PDF file, which the app would either email or store through iCloud, Dropbox, or some other form of file sharing.
The catch with #4 is that that PDF file must remain editable by standard PDF applications on Windows and Mac (Acrobat, Preview, etc.), so all the fields need to remain. And the PDF should be viewable just the same on either Windows or Mac.
Now, at NO time will the PDF (neither the original nor the exported final document) EVER need to be displayed inside the iOS app, nor would it make much sense to be able to do so.
I don't know if any of this is possible. This is our first iOS project, and we've been leaning towards building the app using Moai or Corona or some other framework to save development time and make porting across platforms easier. That said, if it cannot be done using Lua and one of these frameworks (I remain skeptical...they seem HIGHLY geared towards games), we're not opposed to doing it directly in Objective C and building an Android version some time down the road.
But either way, I'm at a loss in assessing whether this is even a practical undertaking. Our requirements are clear, and frankly if this can't be done, the project won't be pursued any further. But I could definitely use some help from you folks in identifying what my options are, whether I can do it in Lua, and what SDK(s) would be most useful in accomplishing this.
Based on what you've said, it seems that there is little reason to do the PDF-based part of the work on the mobile device itself since:
you don't need to display it on the ipad
you plan to email it or store it in the cloud
if you write this for iOS you will have to write again for Android as you've mentioned
Can you simplify the mobile part of your requirement by focusing on the data-collection and validation, then firing off to a server to do the document production? That will give you a lot more flexibility in the tools that you can use to merge the data into PDF docs. If so you could look at creating PDFs or populating the fields from code using something like iText (C# or Java). If you don't want to build your own back end server you could try something like Docmosis Cloud - but that might not allow you to get your precise layouts.
Certainly the catch you mentioned - needing to keep the PDFs editable with their fields is a significant gotcha in all cases. If you could convince the stakeholders that it is better to generate the final documents from your system (generate draft, review, update data, generate again etc) - rather than generating editable documents that you then lose control and tracability over, then you will be miles ahead.
Hope that helps.
Did you consider just generating a new pdf using an image of the form as the background to the pdf and just writing the user's data into the required areas over the form image. Would reduce the complexity of trying to parse the original form PDFs.
That's a point of worthwhile discussion, but one we don't have an ideal answer on. I tend to think of that as the almost perfect scenario -- it'd be considerably easier to develop. There are two key issues with this approach that have made us table it except as a very last resort:
The users of this product would be working in the field. That field could be quite literally anywhere--the streets of Manhattan, a disaster-stricken area with infrastructure that's been severely damaged or even destroyed, or the most war-ravaged third world country. If it were the streets of, say, Manhattan, there's no problem--their iOS or Android device will have 3G or Wi-Fi access just about anywhere they go. In the latter two scenarios (which are arguably more common in this industry), that connectivity may be very limited. The concern is whether the end user's ability to be productive or to see and share data with their colleagues will be too greatly restricted if they don't have a decent signal. To be fair though, even today they often aren't even using mobile devices, forcing them to go back to a headquarters type location or use radios to share information, effectively negating my point here. But if we're not going to significantly increase their productivity in the field, it just gives us pause to think through whether or not we have enough of a value proposition to ask them to fairly significantly change their methods of doing things.
To your latter point, no there's no convincing the stakeholders that this new system is the better approach. Even if there were, it would take years to do so. These forms are a part of a well-defined, decades-old standard used by literally thousands of organizations.
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.