JavaScript as a requirement?
One of the most important new features that activeCollab 1.0 will bring is improved interface. We spent (and continue to spend) a lot of time on details that directly improve user experience and productivity - things that are commonly accessed are always at reach of your hand, we killed complete page reloads everywhere where possible and makes sense, added a bunch of new controls that make some complex tasks really easy and so on. But, there is catch - you need to use modern browser (IE6+, Firefox or Safari) and you need to have JavaScript enabled.
To make sure that system is working even when JavaScript is disabled developers use a simple trick. We start with a page that just works everywhere, without any fancy tricks. When that code is loaded we use JavaScript to enhance it and add special functionality to it. For instance, we can start with a simple fieldset and use JavaScript to enhance it so it can be collapsed and expanded so we can keep big forms as tidy as possible. If JavaScript is disabled fieldset will not be transformed and the whole thing will use browsers default behavior; if we have JavaScript we will have some nice improvements that reduce clutter and help users do their job faster.
This approach produces better and more accessible system, so there should be no problems, right? Most of the time the answer is Yes, but there is one big question here - does it pay off. It burns a lot of time (meaning money) to be developed and still:
- Most of the people use modern browsers and have JS turned on.
- On websites every visitor counts. You don't have this type of pressure with web applications, especially when they don't have a public interface.
When you put it that way you have this choice:
- Make JavaScript a requirement and focus on brining more value to most of the users instead of hacking around browsers issues and clients that do not support JavaScript.
- Burn time and money on progressive enhancements to ensure maximal compatibility at any cost and have usable system even when JavaScript is disabled.
- Make a system that is usable when JS is disabled but require it in situations when you would end up with a crippled solution in order to ensure compatibility and accessibility.
Not an easy decision to make. What do you think? How many of you use browsers that does not support JavaScript of have it disabled?
Comments:
oh and
no gnatt charts
for example
* make it possible to add a task by email.
* make it possible to complete a task from a task list that can be accessed via a cut down page e.g suitable for PDA/smart phone access.
I’m happy to have full functionality restricted to a modern browser with Javascript On for my desktop use, but would like the option to do basic fundamental stuff, like see what I need to do and tick things off, no matter where or what browser I’m using.
So make it a requirement for the main interface, but create a subset of functions for other UA’s – a different url for the cut down page.
It is not hard to produce a system that works really good even when there is no JS enabled, but if you say that JS is a system requirement you have something strong to rely on.
Just an example: you have a WYSIWYG editor that has a built in image browser. It produces HTML and images are linked in specific way so web application can keep track on relations between images and articles (you don’t want to delete an image that is used in 10 articles and you want the system to warn you about that when you try). In this case working on a solution that would provide a good fallback when JS is disabled would take a lot of time and you would need to explain a few more things to users:
1. Users need to be familiar with HTML when managing articles with disabled JS. Also, it would be good to provide some alternative text formating system that is friendlier when working with plain text (Textile or Markdown for example). This systems are not WYSIWYG editor friendly so you need to figure out a way around that too…
2. You need to explain how users can find and link images in a way that lets system keep track on relations between images and articles.
This whole WYSIWYG scenario is hypothetical but it illustrates how much additional work sometimes needs to be done to ensure that system is completely usable in clients that does not support JS or have it disabled.
I think it’s better than work days on compatibility when you could be extending the system or doing another productive thing.
Go ahead!
Dare I say two interfaces? – A full javascript-based interface, and a severely limited (low graphics, no javascript) interface with fewer functions. (Clearly I’m not going to be looking at graphs and such on my cell phone)
Considering the rise of many mobile devices (smartphones, blackberries, etc.), IMHO one should not ignore this segment, since it will be bigger than the entire PC market. If aC would work too without JS, than it would be usable on many of these devices too.
Just my 2 cents.
M.
You cannot under any circustances force your clients to have javascript enabled! What sort of dictatorship world do you live in? What about people with visual or motor impairments! These people are just as likely to need to use this software.
Collaboration is all about inclusion of people in all sorts of processes. You cannot exclude someone because your code isnt up-to scratch. The responsibility is on the developer to include everyone.
Applications should be built with javascript turned off. ALL essential functionality should be available without css and javascript. Use these feature to make the application special, to save time, to make it more usable, but DO NOT EVER uses these technologies as the basis of any serious web application.
You do not have to include all browsers in progressive enhancement category. You can selectively add them if the underlying application doesn’t require javascript. you add the ones you have tested. Only test and support the main ones.
Progressive enhancement and graded browser support and the keys to building reliable, robust and inclusive web applications.
I love this application, I’d be sad to see it go the wrong way.
Most importantly for me, do whatever it takes to get 1.0 up and running pronto, I’m dying for it!
PDAs/Blackberries etc support some javascript, it just needs to be tested to work with these sort of devices.
Accessibility is one reason. And I’m not talking about blind people here. People using one of the thousands available PDA/phones. People who don’t have js enabled for other reasons (corporate policy? using some older pc in an internet cafe somewhere?)
Of course, you could say that 95% of the time AC is used on a modern desktop with js enabled. But I can imagine that the cases in which Ac is used without js are a few important moments. When you’re traveling, on an airport somewhere. Maybe using an older pc without js when you’re meeting a client somewhere. Etc etc.
Gmail is a good example. Works without javascript. Without all the fancy stuff, but functions well.
Of course you are correct to say it takes some time to build things with progressive enhancement/graceful degradation in mind. But maybe that is a good thing for another reasons as well. It will make you think twice before adding that fancy ajaxy stuff. That cool auto-collapse effect, that cool drag-and-drop thingy.
For the developer, those are the coolest things to work on. But for the average user other things are far more important. Maybe those cool effects are only annoying. or not really necessary.
One example: using ajax to avoid a page refresh. Of course, that can be a good thing. Saves you from reloading a complete page. But with a light-weight html page like that in activecollab, how much of an advantage is that? We’re not talking about a large page full of adds here. A page refresh might even be helpful in a usability sense, to make people aware of the fact that something really happened after they clicked that button.
I’m just saying: think twice before going overboard with all the fancy stuff.
mattijs:
Gmail is a good example. Works without javascript. Without all the fancy stuff, but functions well.
GMail does this by providing two versions of the interface – one that uses JS and one that does not. And there is a special version made for mobile devices.
But, I don’t know the code behind activecollab, so maybe if you have a well-designed framework with a solid API in it’s core, developing a simplified version for non-js or mobile access might be not that hard. You know that better then me.
I think that if one talks about accessibility in software like activecollab, it’s not about having to provide an equal experience to everyone/every device, but making sure the core functionality is available for (almost) anyone. What belongs to that core functionality will need some thinking.
Most probably you’ll not try to manage 500 pages of project documentation with your mobile phone, but I can bet that you will like to see whats on your plate for today or jot down some ideas and tasks while on train or walking to work.
> of have it disabled?
Not me nor my users. :-)
Regards…
However, mobile access is not MUST it’s something that is nice to have and therefore I do agree with lmtsypin, if you can faster come up with 1.0 and this can be added later it would be a good reason to leave it out for now.
I’m really looking forward to seeing 1.0!
the kind of company with an IT policy of having browser javascript off IS NOT THE KIND OF company that is looking for a tool like ActiveCollab.
Personally, I think the ‘javascript-off’ movement petered out about 18 months ago, when “web 2.0” started to seem fun, XP SP2 and Firefox started to win the popup war, and designers & usability experts finally started to admit that section 508 accessibility fanaticism had taken over the goal of making good web experiences for users.
If you can make the pages *readable* without JS, that would be good accessibility, and probably quite achievable. Graceful degradation of editing features would be admirable, but frankly, Google has a bigger budget and more programmers than you do. Keep the productivity improvements (for the majority of us – javascript on) coming, the speed at which you can develop them – while still keeping simple – will have a much bigger impact on ActiveCollab’s success and popularity.
Good look.
Applications have and will always have requirements that restrict some users not having/using them. This requirement could be price, hardware, browser settings etc. It’s really not developers responsibility to make application to work with every single piece of machinery out there! It’s developers reponsibility to make application that works smoothly in enviroment that fits for the needs of application (and the needs of the many, not the needs of the few) and after that (maybe) provide API to those users that doesn’t want or can’t, fill requirements to make their own limited UI versions.
ActiveCollab already requires PHP5 on the backend, I doubt the people who are actually interested in installing and running this software will have JavaScript turned off.
JS required until 1.0, then compatibility with other devices can come later.
For people on the “it should work with html-only” boat, I’d like to suggest that aC is a project management application, not a Web site. Sure, you could use SquirrelMail for your web-based client, but there’s a reason Gmail/Hotmail/Yahoo are popular—they provide a rich interface that is easy to use. (Of course, they do have millions of dollars to devote to building 3 different interfaces to the same app-rich, mobile and blah html). So maybe down the road aC can do the same. But out of the box, I think building with Web2.0 in mind leads to quick market adoption.
Let’s face it, people using aC are probably using JS…so when you say 80/20 within a real specific user set, we’re talking things like Firefox vs IE7, not JS vs not.
While standards compliance and KISS are definitely not things you toss to the wayside for the sake of cool, building a highly usable app probably comes before a highly compatible app.
Thats where i stand.
The WYSIWYG example is directly on point. Lose WYSIWYG = lose far too many of exactly the users you need, at precisely the time you need them most. So yes, this really is 80:20. Work on the 20% later – if needed.
Have to chime in with a NO here. Requiring JS violates basic principles of accessibility, for no good reason. I and the company I work for develop modern AJAX web apps that will gracefully degrade in the absence of JS. Moreover, baking JS/behaviour into the application is not ideal development practice (Something Ilija actually mentions himself in another post).
Its not that hard to build the app and use progressive enhancement on top of it for DHTML/Ajax effects, and it makes development easier, and is certainly much better for users. This is good opportunity to improve on basecamp by following best practices.
You are completely right. I mixed up 80/20 rule with statement in Apple Interface Guidelines that says that one of the best ways to avoid feature bloat is to throw out everything that does not benefit at least 80% of users. Sorry, my bad…
Whole point of this discussion is that there are situations when focusing on features that would benefit majority of users is a better thing to do than to seek perfection that minority will benefit from.
Thanks to all who commented. activeCollab 1.0 will be designed to work even when JS is off, but some advanced features that are hard to implement when JS is not enabled will not be available in that mode. They will be implemented later on…
I’ve been using the Basecamp and I know its faults.
Ako mogu nekako da pomognem, samo javi.
What about those wireless devices? I personally hate “browsing the web” on my Treo and would much rather have support for applications on an application by application basis. I could visit Gmail from my treo’s web browser but it’s a pain in the rear—instead I use Gmail’s mobile edition installed to my Treo. Same for activeCollab. Mobile devices could (and in my opinion, should) be supported by an application using RSS to retrieve data. Result? Faster data access, better UI, easier coding on everyone’s end.
In terms of the issue of supporting those with visual/motor impairments, I don’t know much about it. I will say, however, and this is outside the scope of this debate but i’ll include my theory here anyway, that it seems to me that this should be handled by a third party software and I’m surprised it isn’t currently. Wouldn’t it make sense to have a program that takes an XML input and figures out how to display it BASED on the impairment? This makes sense to me because everyone is different: when dealing with visual impairments the problem may be color related or may be related to size, and with motor impairments, the UI might have to be completely reconfigured to make it easy to use. It seems wierd to me that programmers for every website should have to figure out how to handle different handicaps (especially considering ththere’s no way they’ll be able to include everyone) instead of just opening access to some sort of predefined data (via XML or something) that would be processed by a program that the user would configure for himself to best suite HIS needs. Just a thought…
Noah
João Saleiro
PS: And also, building it with Flex 2 will allow to create also a deployable version using Apollo.
PS2: I imagine that Flex 2 won’t be considered as a option for one or two reasons (lack of knowledge of the language, for example), but at least i gave it a try. Personally, i do know Flex 2 power, and it’s the right (and only) choice for this kind of tool.
I’m new to activeCollab, maybe it’s too late for comments on this question?
Anyway: I agree with some others: Make it as near to a desktop application as possible. People don’t use web applications of this kind if they feel too slow or complicated. They got work to do and waiting for page refreshs etc. is not very productive.
Make JS required. For mobile phones provide special frontend with only the core functionality (maybe configurable?)
bg
Jan
Later on in development when there is tie, work on creating a better fall-back for users with javascript disabled.
so if you are adding js to slick up the user interface, make sure you do it right so the app still functions without it.
the second half of that is already done, so all you need to do is add the layer.
This is an open-source application, not a commercial one. This means that the developers can’t spend every minute of their working day making the application as backwards-compliant and degradable as possible.
Whilst as a matter of principal, it’s never a good idea to make JavaScript a requirement, in this situation it’s just not feasible. (Developer time restraints)
Making JavaScript a requirement certainly wouldn’t be a problem for me or my clients, or any future clients. All modern browsers have JavaScript support.
For those who are concerned about mobile devices support, Opera Mobile and Opera Mini have excellent support for JavaScript (support many of my Prototype-powered sites nicely), and mobile device support for JavaScript will only increase in the future.
For very basic mobile devices, good RSS feed support would help cater for them, and with the API that’s soon to be implemented, a mobile-only / more accessible interface could easily be added.
I also feel that if you consciously take the step to turn javascript off, then you cannot be surprised that many modern sites will not work as intended, or at all. I cannot burn my client’s budget accommodating the few that have already decided they’re okay with certain things not working.
Am I alone on this thought?
So yes add javascript enhancement, but don not require them, it is perfect possible to do using any decent framework
But today even on big general interest sites you have 98 percent of the visitors browsing with JS turned on. Lynx zealots beware: if zimbra doesn’t work without, why should aC work without JS?
Make JavaScript a requirement and focus on speed, usability and an intuitive user interface.
activeCollab is an application, not a public website for people using very old screen-readers without JavaScript support.
Ilija – are you still going with your decision to make activeCollab 1.0 work with JavaScript disabled?
It seems like the general consensus here is strongly in favour of making JavaScript a requirement…
I think that’s the way to go, use javascript to enhance to interface, but make sure that even without javascript people can do basic stuff, like I said before this is pretty easy with a decent framework.
Thanks
Peter
The statement in Apple Interface Guidelines about 80 is a consecuence of parerto’s 80/20 rule.
About what mattijs said “drawback to that might be that it can be a lot of work to keep developing several versions”
1st one JS tier.. later go mobile. IT’s not so much drawback… mobile versions simpler… but real interesting because the king of people using this solution (project management) and watching the technology evolution of telecomunicaction and Information system convergence.
Anyhow..
JS YES. And I think the Oscar goes to JS.
Now Active Collab uses YUI library… it’s a lot of js. Isn’t it? Keep on it!
But I’d like to say some issues to consider in the evolution of this politic of development:
JS’s as a no-functional requirement that serves the funciontal requirement of rich interactive UI. :)
JS’s is in UI… not buness tier.
So JS should only be used for UI responsabilities.
You should aproach with a at least 2-tier design pattern
I’d divided the tiers this way:
(always the data tier)
real business tier
integration tier | (2 UI Tier: WebJSAJAX tier, Mobile devices Tier)
For the mobile tier you should choose between a web tier or an java or .NET tier integrated through the integration tier. Funny deliberation.. you could open another blog debate about it.
Ok. what else can I say… I COMPLETELY AGREE:
“However, mobile access is not MUST it’s something that is nice to have and therefore I do agree with lmtsypin, if you can faster come up with 1.0 and this can be added later it would be a good reason to leave it out for now. ”
Enjoy this great app I love and would love even more if it goes js and later improves with this idea of tiers including mobile acces tier.
Don’t take the time to make a JS compatible site and an NON-JS compatible site. I think certain features could require it, but the whole site requiring it does limit some possibilities.
GREAT WORK!!
But the reality is that you can never predict the needs of people. Even in my office of about a dozen people, everyone uses different software and has different preferences on how to use that software.
While I’m not a zealot, progressive enhancement is the way to go, you just have to decide where to draw the line. In my day-to-day, I still support IE5 (not 5.5, 5) because that’s what our people use. For activeCollab, I imagine you could easily get away with supporting modern browsers only (IE6+ and the rest).
Personally though, one of the requirements for me is that I need to be able to access activeCollab from my pda. Without that, it’s effectively useless to me.
I guess my vote is is contingent on development efforts:
IF having graceful degrading of JS features pushes the 1.0 release out by MORE THAN an extra month, then my vote is to require JS and get it out sooner.
On the other hand, if it only (ha ha ha ha) pushes the release out less than one month, then spend the effort to make it degrade elegantly.
The issue to me is of cost (in time and effort) versus benefit (to a small subset of users).
I think the benefits of HTML-only (that is, no Javascript) to the visually impared is certainly tangible, but not at the cost of delaying the use to everyone else by a significant length of time. aC is generally for business (or at least, “professional”) use, and notused by some general web surfer looking for information about pets: the bar is raised higher for this sort of user, and the JS requirement is considered to be “a cost of doing business” in my book.
I think the argument that mobile access is the reason to make JS optional is bogus. I surf sites all the time on my Treo, and honestly, really using websites that aren’t specifically formatted with mobile access in mind is painful. Both my personal webmail (running on my personal server) and Gmail have specific “mobile access” versions that are actually fast and pleasant to use on my treo, whereas the regular versions aren’t.
If you really care about mobile access to aC, then add a new streamlined interface optimized for it, even if it is feature-reduced. Add it after the 1.0 release if necessary. Make this “mobile skin” accessible via a different URL, or enable a “use Mobile Interface” checkbox at the login window. Maybe make it “read only” or provide only limited options.
The mobile browser environment is just too limited to make it the lowest common denominator for the mainstream user. Deal with it seperately and lovingly, and watch the mobile professinal flock to aC.
Although it can sometimes enhance a web sites functionality, the vast majority I encounter, on the sad occasion that I have it turned on, is a big PITA. Even when it is used well, it must degrade gracefully. What if I’m blind and using a reader? wernst claims that for business the bar can be higher and calls Javascript “a cost of doing business,” which is great, but I’m still blind and can’t use your application. It’s always bad pedagogy to make assumptions about your users.
Admittedly, there are only a hand full of people using NoScript and the like, but they’re largely tech nerds, that is, folks who are likely to make decisions about what project management software will be in use. 80% of the potential users may love Javascript, but if your software can’t make it past that one guy in IT, they’ll never see your application.
take for example basecamp, im sure the ui would not be nearly as good without javascript and would definitely require more page refreshes.
Virtually all my web access is carried out through a college network based PC via a proxy server. To protect the college network, when logging-in the brower automatically has script disabled, and accesses to the settings page is also disabled.
A little heavy handed I’ll agree, but that’s how it is, and I’m sure many other college and corporate networks will be the same. Making JS a requirement will remove activeCollab from the reach of many potential day to day users in environments where collaboration is an essential element of their roles.
but, if aC is going to be competitive with things like basecamp, you definitely NEED the javascript option. at the moment the lack of an ajax interface makes a lot of things slow and cumbersome…
Clearly say that you need Javascript where you DO need it, and fail gracefully if you cant have it.
Note that I did not say “degrade gracefully” which usually means writing 3 copies of code. This decision benefits you as well, as the simplicity forced will keep the app fast and responsive. I beta tested Micrsoft Hotmail Live and went back to the “limited version” similarly on Yahoo, I use it with JavaScript off. Why?
Bloated, laborious sluggish code I swear, if I ever see that fcking ajax spinning crap again!.......
The API will help a lot, and RSS feeds too. Those should provide the accessibility that you should have.
Also, I think it would be great if I could get task updates using Gopher. Don’t ignore this important technology just because you’re too lazy to implement it.
Another great feature would be to mashup with Google Paper and provide overnight mailings of printouts of all important changes. Not everyone has a computer and it’s not right to leave them behind because you can’t be bothered to spend the extra 5 minutes to implement these features.
I’d be willing to do testing under opera (and Nokia’s S60 browser based on webkit) if desired. Any other opera users out there? Speak up!






Paul Armstrong
2007-03-10 5:20
I’ve never felt that needing to ensure maximal compatibility at any cost was actually that difficult or time consuming… really it makes me feel pretty good to be able to make things completely usable without Javascript and/or CSS while still having an amazing interface to work with.
But in the end, activeCollab is a software that no one is being forced to use or absolutely needs to use it. You should do what is best for you and the product.