I'm a software developer. The only browser I have at work is IE7. I don't have freedom to select my browser.
I am constantly learning and researching things online and, of course, IE7 is a very poor tool for doing that work.
I've been invited to present a business case for replacing the dev team's IE7 browsers w/ a something more modern. I don't want browser recommendations, and this isn't about which browser the users of my software/webapps will use, but...
... what behaviors/traits/sideeffects of IE7 should I highlight when making the case that it has a very real negative impact when I'm trying to do my work as a software developer?
Do I talk about security vulnerabilities (on my workstation)? Do I talk about the cost of waiting for tabs to open all day? Do I talk about the memory leaks? Do I try to measure how often the browser just flat-out crashes on me? What would resonate best with the corporate decision makers?
Words that important people like to hear:
Security (use open security vulnerability charts and such)
Standards (talk very briefly about web standards, but then hammer in the point that IE does not follow them throughout the presentation)
Productivity (here's where you get to talk about speed, additional features etc)
Also make sure to talk about the minimal cost that the switch will have in terms of IT time required.
You did not explain what you are developing, and who you do it for. If you develop for an audience of 15,000 IE7 users, I think you have a weak case.
If you develop public websites, you have a very strong case, and many arguments to support it. It all depends ....
Related
A developer buddy of mine just recently started at a new company and one of his tasks is to come up with a new web application that allows their users to work offline when their staff are onsite in remote locations and then later to sync with a server side database of which they have not yet determined a server side provider yet (i'm guessing it will be SQL Server).
I've done some looking around and it seems like two viable options are LocalStorage and IndexedDb, with LocalStorage being the more popular technology? They want to go HTML5 and that's all fine and dandy, but long story short my question(s) is/are...
What are their offline data storage options in HTML5?
Are there older solutions that have better support?
are those methods less risky?
less time to implement?
The concept of storing data offline in a web application doesn't seem like a new idea, but doing so in today's newest technologies (html5, asp.net 4.0/4.5) is where you start getting into sparsely explored territory.
what are some things that maybe your company does that works, and what doesn't work?
Any intelligent evidence based replies will more than likely get my upvote so don't just rush to get the first answer and try to score some quick points, I'm looking for some good solid feedback here. Thank you.
There are several possibilities of offline storage in HTML5:
Web Storage
Web SQL Database
IndexedDB
Filesystem API
You have a very good presentation of all these options here:
http://www.html5rocks.com/en/tutorials/offline/whats-offline/#toc-older-storage
Compared to older options (Cookies, Plugin Based Storage, Browser-specific features) , I'll quote from the article:
"The newer storage APIs, what we might call "HTML5 storage", are generally superior in terms of openness and standards compliance. Of course, not all browsers include all of the new APIs, and you may have to support older browsers that don't include any of them at all. So the older techniques are still useful for graceful degradation."
Other useful links:
http://php-html.net/tutorials/html5-local-storage-guide/
http://www.tutorialspoint.com/html5/html5_web_sql.htm
Hope this helps...
I think your best choice is using Local Storage since its the most widely implemented standard of the storage options available under HTML5.
IndexedDB has been over-engineered (in my opinion) and is not widely supported (yet) for all of Mozilla's insistence that its better than sliced bread, and WebSQL's future is looking a bit uncertain as Mozilla is refusing to implement it and it is no longer being worked on due to an impasse between W3C and the browser vendors who have actually implemented it (Chrome/Safari/Opera).
There is currently a bit of a browser explosion happening thanks to smartphone adoption, so its hard to determine how much of the market supports HTML5 LocalStorage features but using statcounter I've been able to calculate that between Chrome (4+), Firefox (3.+), Safari (4+), Opera (10.5+) and IE (8+), including iPhone and Android devices you'll have captured around 80-85% of the market, with this figure going upwards a rate of 1-2% per month. The remainder being IE 6/7 (which stubbornly tends to hang on), older versions of new browsers (with update features that generally kept them current), and some mobile browsers stuck back in the stone age.
As for older options, I would add User Data Persistence for IE6/7 to the list provided by #user998692 but either way you're going to be caught up with lots of browser incompatiblity issues and support for a hodge-podge of technologies, which will complicate your codebase and testing and increase your delivery timelines (and cost) accordingly. If you do want to go down this road, however, I would recommend you take a look at PersistJS as the guys who put it together have done much of the work you would need to already.
These days its worth more looking forward (to what the market will look like in 1-2 years time when your app is propagating and gaining a wide user base) than backwards, so I'd say HTML5 LocalStorage is probably your best option.
I'm not a Silverlight developer (yet) and what is putting me off - and many others, I think - is the relative lack of browser installations of it compared to Flash.
But I'm not clear on why website visitors have to explicitly install Silverlight themselves - which appears to be the major stumbling block.
Since the vast majority of computer users use Windows, is there a reason that Microsoft are not forcing Silverlight onto Windows machines through a Windows update?
They do this (and continue to do so) with the .NET framework runtimes, so why not with Silverlight? Legal issue, perhaps?
Getting sued by all its competitors is what stops this
There are several reasons why not to do it.
Users should have choice over what gets installed. I realize from a developer standpoint we know some users who are clueless about what this software does, so why put the choice in their hands? Fine, MS should make it easy for users to install it if they don't have it when they visit a site that uses it. Then they can make an informed decision. Do I want to use this site or not?
Corporate Approvals. Companies go through software validation procedures and that is why some will still be on XP for some time. If they were forced to validate these pieces because microsoft was forcing them down the pipe, they'd be pissed off. So thus MS gives corporations control over the windows updates that get approved/installed. And corporations are where MS makes their money.
PC Manufactures choosing what software to preinstall. Here the manufacturers have the ability to push silverlight or not.
Competitor's software isn't automatically installed. You actually have to install flash. Some PC manufacturers might bundle it with the PC but if you install yourself or for a corporate deployment, it isn't there by default.
The monopoly power abuse concerns mentioned. But I think this is actually the least important reason.
Silverlight won't hit mainstream adoption till there is that one app that everyone must have that uses it. Like the office online example above.
I think that would be the wrong way to go about trying to gain adoption. The product should merit installation on it's own, not lean on the Windows installation base for support. Writing the free version of Office online (EDIT: I meant the Office Web Applications) in Silverlight, however, is a great way to gain adoption (even with the non-SL version available too http://blogs.msdn.com/officewebapps/archive/2009/08/05/9858563.aspx).
Also, since this is a browser plugin, how would that work? Can a Windows update install plugins for firefox, opera, or whatever browser the user prefers? Doesn't seem feasible to me but I'm really not sure.
They actually suggest it in Windows Update. I politely refuse it.
There may be an anti-trust reason for this also, remember what happened with Java, even when it was from Sun they still had a problem with it.
If you keep waiting for Silverlight to catch on, it never will be enough, start developing now and when there are many great web-apps that support Silverlight then maybe it will get more popular, plus it is very easy to install and you can target Mac and Windows, and some extent Moonlight too as it reaches support for Silverlight 2.0 and some 3.0 there may be Mac-Windows-Linux apps you can write.
I recommend Silverlight to anyone who develops in .NET, I am a little biased as I'm writing an application at the moment in Silverlight.
I suspect that they are waiting for the technology to mature and/or gain more acceptance. Once a critical mass of sites and/or users have it installed they might do.
The other alternative is that they might be waiting until they've completed the "merger" of WPF and Silverlight. I can't see them continuing to keep these two very similar technologies separate.
After all Adobe don't force Flash on everybody.
Can't speak for Microsoft, but I am dismayed by the question. I don't want extra crap pushed to my machine (or into my life in general). I only want extra stuff if I pull it. Stuff like that should always be "opt in" instead of "opt out" or "no option at all."
The european union has filed anti-trust suits against Microsoft which is probably why they don't put it in their updates.
I however don't install it because i don't like unnecessary processor cycles being used up for advertising much in the way that flash is used. Flash I've uninstalled on many of my computers in protest, though i admit it's on my media center in the living room because people use it for you tube.
For all the hype, Silverlight is not all that great to develop in and doesn't bring anything to the user experience that couldn't be better achieved through dhtml/ajax.
I've just discovered J2ME and I love the possibilities that it presents. I'm currently working on a simple application and I'd like to maybe release it as an open-source project sometime in the future.
As part of my research into J2ME and mobile devices, I looked into applet signing. It seems that people who want to create applets for free are caught between and rock and an awful shite-place. Applet signing is extremely expensive and extremely convoluted - and the expense can't be justified when coding for free.
There are a huge number of J2ME compatible devices out there - I think it would be a shame to have to ignore them, and just wait patiently for the next wave (e.g. Android).
I was wondering if other people have any ideas about ways to approach this problem?
UPDATE: I found this blog article which summarises the problem for those interested... http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/
I thought about setting up a non-profit umbrella organisation for open-source J2ME developers who want a VeriSign certificate (as a certificate can sign code an unlimited amount of times). I would aim to raise the $500 and then enable group members to share the purchased certificate. Had a quick chat to a VeriSign rep and they thought the idea could work (as long as the organisation was registered as a legal entity).
However, since handset manufacturers now seem to be moving to support only UTI root certificates (which you can only get through the 'Java verified' programme) - this might not be as useful as I thought it could be... if anyone has any ideas would be great to hear them.
I am afraid that you are fighting a battle that you can't win. Using the restricted APIs is getting harder and harder and this is not accidental. As you've read in the blog entry you've mentioned the biggest problem is the network operators. Even if you buy a certificate from Verisign or Thawte (which is by the way cheaper), your application won't run in network operators branded phones, since these have their own CA rules.
At first it was possible for a developer to install his/her own certificate, but even this is now not possible. This strict rule is mandated by the phone manufacturers (Nokia for example) and applies to all phones (even no branded ones). I believe that this too is not accidental and is mainly because of pressure put to device manufacturers by the network operators.
Finally, although MIDP 3.0 has been announced for years, nothing has really come out of it. It seems that even Sun believe that J2ME is only for games.
All of these have been extensively discussed in J2ME forums for a long time. The general consensus is that the network operators do not want to have every phone available in the market operate as a smart phone and be able to run a third-party application. Then it will be very easy for everyone to use a cheaper, web-based alternative instead of SMS messaging for a example. This may sound as a conspiracy theory, if you are new in the J2ME world, but have in mind that network operators sell phones with their own firmware that lock even basic functionalities (e.g. transferring photos via Bluetooth or using MP3s as ringtones) to force the owner to use paid services!
I don't know if this is going to change now that smart phones (iPhone, Android, Windows Mobile) are gaining momentum. Have in mind that restrictions apply also for these platforms (notably Symbian, which is also very unfriendly for open source).
You can create a signing certificate
that you self-sign. Your users have
to be willing to trust you.
You can instruct your users how to
create a cert and self-sign with it.
Then the users have to be able to
trust themselves.
There are more or less open CAs; you
have to be willing to trust them and
convince your users to trust them.
The Java Tutorial has a section on signed applets that will lead you through the steps.
I'm a J2ME application developer and i totally agree your post. The costs for signing a MIDlet are simply unaffordable for open source initiatives and unless your're developing simple games, you'll soon or later end up in using restricted APIs to access sockets or Location API just to name two of them. This is very frustrating and if you consider that the permission policies are not always threated the same on various devices, the thing get worst: on some mobile phone you can tell the OS to trust the entyre MIDlet and never bother you at all, other continue to ask you permission every time you call for a restricted method. It's tragic!
I rellay appreciate your proposal and i think it would be a great achievement for JavaME developers.
I am going to write a database application for the camp I work for. I am thinking about writing it in C# with a Windows GUI interface but using a browser as the application is seeming more and more appelaing for various reasons. What I am wondering is why someone would not choose to write an application as a web application. Ex. The back button can cause you some trouble. Are there other things that ayone can think of?
There are plenty of cons:
Speed and responsiveness tend to be significantly worse
Complicated UI widgets (such as tree controls) are harder to do
Rendering graphics of any kind is pretty tricky, 3D graphics is even harder
You have to mess around with logins
A centralised server means clients always need network access
Security restrictions may cause you trouble
Browser incompatibilities can cause a lot of extra work
UI conventions are less well-defined on the web - users may find it harder to use
Client-side storage is limited
The question is.. do enough of those apply to your project to make web the wrong choice?
One thing that was not mentioned here is the level of complexity and knowledge required to generate a good web application. The problem being unless you are doing something very simple, there is no "Single" knowledge or technology that goes into these applications.
For example if you were to write an application for some client server platform.. you may develop in Java or C++. For a complex web application you may have to have expertise in Java, Java Script, HTML, Flash, CSS, Ajax, SQL, J2EE.. etc. Also the components of a web based application are also more numerous, Web Application Server, HTTP Server, Database, Browser.. are tipical components but there could be more.. a client server app is tipical just what it says.. a client application and a Server application. My experience and personal preference is not web based .. web based is great for many things. But even though I am an IT Architect for a leading company that is completely emersed in Web Apps as the solution for everything... The cons are many still.. I do thing the technology will evolve and the cons will go away over time though.
Essentially the real limitations are only through of the platform, being the browser. If you have to account for all browsers in current use that can be a pain due to varying degrees of standards in each of them.
If have control of the which browser to use, that is everyone is on computers that you control on site, and say you install firefox on all of them, you could then leverage the latest Javascript and CSS standards to their fullest in your content delivery.
[edit] You could also look into options like the adobe integrated runtime or "AIR" as an option allowing you to code the front-end with traditional browser based options like xhtml/css/javascript, flash/flex and have the backend hooked up to your database online, only also providing functionality of a traditional desktop app at the same time.
The biggest difference and drawback I see with web applications is state management. Since the web is, by nature, stateless every thing you want to maintain has to be sent back and forth from the server with every request and response. How to efficiently store and retrieve it in a matter with respect to page size and performance is hard to do at times. Also the fact that there is no real standard (at least not that everyone adheres to) for browsers makes consistency really..........fun.
You need to have a network access to the server that you are going to have the web application on (if there are going to be multiple users for the application - which is typically the case).
Actually, there are more pros than cons - if you can give some details about your application, we could help a little more...
It completely depends on the requirements of your project. For the most part, there isn't much web applications cannot do these days. Admittedly, certain applications do belong on the desktop as browsers (while currently advancing, and rapidly), still are not quite there yet. From the advent of applications such as Google Docs, Gmail
There isn't much you -cannot- do on the web. If you're creating a World of Warcraft competitor however, the web is most certainly not the optimal solution. Again, unfortunately we'd need more insight on the application you're building for the camp. The best part about the web is that anyone with a browser can use your application.
Web applications delegate processing to a remote machine. Depending on the amount of processing, this can be a con. Consider a photo editor that's a web app.
Web applications also can't deal with a whole lot of data going back and forth to and from a client. You can watch video online.. when it's compressed. It will be awhile before we see any web-based video editing software.
Browser compatibility is also a hassle. You can't control the look-and-feel of the application 100%.
Vaibhav has a good point. What's your application?
A major one is down time for migrations... users will not expect the application to be down, ever, but realistically it will have to be down for major upgrades. When doing this with a desktop application, the user (or end-user systems admin) is in control of when upgrades happen; with an online app, they're not.
For applications which have large data, performance can be a major problem as you're storing a large number of users' data centrally, which means the IO performance will not be as good as it would be if you gave them all a laptop.
In general scalability gives problems for a server-based app. Desktop applications scale really well.
You can do an awful lot with a web-based app, but it is a lot easier to do certain things with a thick client:
Performance: You get simple access to the full power of the client's CPU.
Responsiveness: Interactivity is fast and easy.
Graphics: You can easily use graphics libraries such as DirectX and OpenGL to create fast impressive graphics.
Work with local files
Peer-to-peer
Deciding whether a web application is a good approach depends on what you are trying to achieve. However here are some more general cons of web applications:
Real integration with desktop apps (e.g. Outlook) is impossible
Drag and drop between your app and the desktop / other running apps
With a web application, there are more privacy concerns, when you are storing user data on your servers. You have to make sure that you don't loose/disclose it and your users have to be comfortable with the idea of storing that data on your servers.
Apart from that, there are many security problems, like Man-in-the-middle attacks, XSS or SQL injections.
You also need to make sure that you have enough computing power and bandwidth at hand.
"Ex. The back button can cause you some trouble."
You'll have to be specific on this. A lot of people make fundamental mistakes in their web applications and introduce bugs in how they handle transactions. If you do not use "Redirect after Post" (also known as Post-Redirect-Get, PRG design), then you've created a bug which appears as a problem with the back button.
A blanket statement that the back button in trouble is unlikely to be true. A specific example would clarify your specific question on this.
The back button really is not that much of an issue if you design your application correctly. You can use AJAX to manipulate parts of the current page, without adding items into the browser history (since the page itself wont change).
The biggest issue with designing web applications has to do with state, and the challenges that need to be programmed around. With a desktop application, state is easy to handle, you can leave a database connection opened, lock the record and wait for the user to make the changes and commit. With a web application, you could lock the record...but then what if the user closes the browser? These things must be overcome in the design of your application.
When designing a web application, make sure that each trip to the server "stands alone" and provides a complete answer. Always re-initialize your variables before performing any work and never assume anything. One of the challenges I ran into once was pulling "pages" of grid data back to the user. In a real busy system, with record additions/modifications happening in real time, the user navigation from page to page would vary greatly, sometimes even resulting in viewing the same set of a few records as new additions were added in-front of the query.
Speaking entirely in technology-free terms, what is the best way to make a mobile friendly site? That is, I want to make a site that will work on a regular computer but also have mobile versions of the pages. Should I rewrite each page? The pages will probably have different functionality, so should I rewrite the backend code? Should it be an effectively different site with the same database?
On my site, I detect user agent, and for known mobile browsers I serve a different stylesheet, with some larger/less necessary items left off some pages. The backend doesn't really change.
I added a mobile presentation layer to an operational site about a year ago. Based on the architecture of the site (hopefully this isn't too technology dependent for you) I added a new set of JSPs to accommodate mobile browsers (sidenote: see http://wurfl.sourceforge.net/ for a great way to build mobile pages independent of browser type). Additionally some of the back-end functionality was changed due to the limited functionality of most mobile browsers. So, in short, the integration wasn't as painful as one would expect.
Good luck!
This is a pretty broad question, but here goes:
If the site is primarily about the content, meaning it's not so much a service you use as it's a publication you read, then I'd try to avoid publishing two sites wherever possible. Concentrate on simple presentation using mature technologies that mobile browsers can handle fairly well.
If it's essentially a software application delivered via the network, then things get trickier, because you're going to want to consider the UI of the mobile device, and how it differs from the desktop.
This should go without saying, but either way, if you have many mobile users, you should keep that in mind when you author content for the site. Formats, length, voice, etc.
In addition to the WURFL / WALL capabilities system that todd mentioned, there are Java Server Faces libraries available that use alternate WML renderkits for mobile phones.
One way I have done it in the past was to make sure my data was abstracted well in the data tier and then use separate middle tier models to pull what was appropriate. In my case the application was a weather application and the display methods of the target devices were really limited so we opted to only show the user the essentials on the mobile devices while the website was full featured. That was probably 10 years ago when WAP was big. But these days with devices getting bigger screens, better bandwidth, you may want to consume and display the exact same data with a different view model.
I never really know what type of application will need to consume the data in the future. We do a lot of apps across platforms but the domain model rarely changes. So I end up using the same middle tier objects where I can and pulling that data in different clients. A good example of this is a recent project where we had a rich internet application (widget), a full website, and a web service consuming the same data. Data abstraction in the middle-tier really shines in this environment.
On a very high level of abstraction, there are two main caveats with mobile devices: (1) their screen is small, (2) their network connection is intermittent. This basically means that your need to present the content so that it looks fine even on a small (variable size) screen, and preferably make it cacheable too so that your users can browse the content while offline. Then there's also the problem of low bandwidth and high latency, but those are slightly less important nowadays.
This is a very thorough overview of how to make a site mobile, though i hope its fair to say that there will always be different requirements for anyone seeking to go mobile. If you have a Blog, then you could just as easily make it mobile friendly using Mippin Mobilizer; its free, provides branding customisation tools, and with a big audience already browsing a wide mix of mobilized content, there's opportunities to generate advertising revenue around your blog.
This is because the Mippin Mobilized blog then becomes part of a much wider community of content, people, news, blogs, listings, all connecting around content, and much more at the mobile site:
http://mippin.com (on a mobile browser.)
Take a look at the Mobilizing tool because it shows off what the site can do in a second:
www.mippin.com/mobilizer
Only if you have a blog of course...