JavaScript as a requirement?
JavaScript is important for good interface, but is it important enough to be a system 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?
Posted on: 2007-03-10 4:22
Comments:
Make JavaScript a requirement
oh and
no gnatt charts
oh and
no gnatt charts
Make it a requirement, but make it possible to do very basic things by other means.
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.
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.
@Paul: You are 100% right about 80:20 rule. It does not work here…
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.
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.
Make it a requirement. As you say especially when they don’t have a public interface, it’s ok to tell each team member use a modern browser with JS enabled, same for the clients.
I think it’s better than work days on compatibility when you could be extending the system or doing another productive thing.
Go ahead!
I think it’s better than work days on compatibility when you could be extending the system or doing another productive thing.
Go ahead!
The only reason I would say to not have Javascript as a requirement is that you need to make some functionality available to mobile devices. The ability to do this time of management while away from a computer is essential.
Normally I’m ok with dropping all backwards compatibility – except that I like to access things on my cell phone.
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)
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)
I’m for #3.
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.
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.
There should be no need for 2 interfaces, with not particularly difficult combinations of css and javascript and good practice you can create an application that works in any situation. Progressive enhancement is the key.
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.
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.
Make JS a requirement, the 80:20 rule does apply here, as it does in almost every single business/development question I can think of where time/money is a motivating factor.
Most importantly for me, do whatever it takes to get 1.0 up and running pronto, I’m dying for it!
Most importantly for me, do whatever it takes to get 1.0 up and running pronto, I’m dying for it!
I think that’s impossible to surft the web with javascript turned off today :) Personally I need not any special ajax features available in AC.
Make JavaScript a requirement
PDAs/Blackberries etc support some javascript, it just needs to be tested to work with these sort of devices.
PDAs/Blackberries etc support some javascript, it just needs to be tested to work with these sort of devices.
Do not make js a requirement. So that’s 2 or 3.
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.
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.
Aha. So those are completely separate versions? A drawback to that might be that it can be a lot of work to keep developing several versions. (Google probably has enough people working on it though .. )
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.
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.
Completely agree.
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.
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.
> How many of you use browsers that does not support JavaScript
> of have it disabled?
Not me nor my users. :-)
Regards…
> of have it disabled?
Not me nor my users. :-)
Regards…
Force a JS requirement in 1.0 to not slow the development, and then add non-js and other accessible support in future versions … Gmail did not work will in all environments off the bat … that came later.
I think it’s important to have mobile access to the services like this but if user has disabled javascript on their browsers I wouldn’t care. Now days I do my web development for modern browsers or handhelds (everything under FF1.0 and IE6 is going to handheld design).
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.
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 say stay with making JS a requirement. On websites I would not go for it, but this is an application, go for the best user interface possible.
I’m really looking forward to seeing 1.0!
I’m really looking forward to seeing 1.0!
If this is going to be a commercial proposition, then at least do it properly.
another vote for making javascript a requirement.
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.
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.
I vote for making js as requirement, and different (restricted) ui layer for pda:s that does’t support all the fancy stuff.
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.
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.
One more vote for making JS required.
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.
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.
If you want to see how to do web/pda well look at the PDA interface for facebook. You can’t be that, very simple access to the most important information in a seperate GUI.
I think the question comes back to “are you building a webpage or an application?” My employer builds an incredibly complex CMS/online community management tool, and while the world of textarea plus knowing HTML used to be enough to run a CMS, the fact of the marketplace is that people expect online apps to play and act a lot like their desktop apps.
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.
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.
Personally, i really dont worry about browsers with JS disabled, unless a client specifically tells me to, or unless im developing for a simpler browser (PDA, PSP, etc), since most people know that Web 2.0 is whats in right now, and most sites are going to use javascript to make their sites look smoother, fancier, and smoother. If they are paranoid about javascript somehow being able to hack their computer and use NoScript or just disable JS altogether, that shouldnt be the developers fault.
Thats where i stand.
Thats where i stand.
I vote yes to javascript – at least until 1.0 is out the door. I’m sorry for those who want handheld compatibility or visual/motor impairments (I know their pain, being hearing impaired myself), but releasing the product should be job one.
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.
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.
JavaScript should, by all means, be a requirement, given the situation that you face.
The 80:20 rule has nothing to do with appealing to 80% of your customer base that exhibits certain behavior and abandoning the remainder who do not comply. The principle is that 80% of business revenues come from 20% of clients. The idea has rule-of-thumb application in many places, but it is commonly misused. For example, it is a misuse to state that a solution to a problem “fits the 80-20 rule” just because it fits 80% of the cases; it must be implied that this solution requires only 20% of the resources needed to solve all cases.
Hi Deron!
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…
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…
If I can help somehow, just say it. :)
I’ve been using the Basecamp and I know its faults.
Ako mogu nekako da pomognem, samo javi.
I’ve been using the Basecamp and I know its faults.
Ako mogu nekako da pomognem, samo javi.
I’m new to activecollab (just found the website 30 minutes ago, downloaded, and installing it on my server as we speak), but the answer to me seems clear: make Javascript a requirement.
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
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
Well, for me there is only one answer. Go with Adobe Flex 2. And make ActiveCollab the next killer Rich Internet Application for project management. Or you do it, or i’ll do it sooner or later when i have time :P. But i think that’s the natural evolution for this tools like ActiveCollab.
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.
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.
Hi,
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
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
To most users, the user interface is the application. Javascript/AJAX makes the interface a much more usable and enjoyable experience. JS is a must.
+1 for graceful degredation. JS can enhance the user experience like nothing else, but keep it open for folks using screen readers. But yes, please do use JS where it can help make a more usable product (uploader status, slide out features for tips/tricks a la Basecamp, etc.)
Make javascript a requirement, there are very few people who disable javascript, and most for security purposes. These users would probably, upon being informed of it’s necessity, add the site using ActiveCollab to a whitelist, effectively eliminating the problem.
Later on in development when there is tie, work on creating a better fall-back for users with javascript disabled.
Later on in development when there is tie, work on creating a better fall-back for users with javascript disabled.
#29 is exactly right. JS should NEVER be a REQUIREMENT, only an enhancement. he is also correct that its not difficult to create that enhancement with graceful degradation.
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.
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.
Your activeCollab installation would never be open to the general public, and so you know exactly who will be accessing your activeCollab install (your clients), so you know they use JavaScript enabled browsers.
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.
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.
Another vote against requiring Javascript.
My vote is to make JS required. While I always strive for as much compatibility as possible on my sites, if a function needs JS to work, I use it. My philosophy is this: for the most part, anyone with javascript disabled turned it off themselves. This is something the average user won’t do.
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?
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?
Just to add my vote against, a couple of reasons: – people using screen readers – people using lotus notes – companies with it policies – mobile devices – probably a dozen more
So yes add javascript enhancement, but don not require them, it is perfect possible to do using any decent framework
So yes add javascript enhancement, but don not require them, it is perfect possible to do using any decent framework
Make JS a requirement. I really can’t stand these arguments any more. Ten years ago this might have been a valid discussion, even if we had working JS then.
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?
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 go for enhanced usability: at the end of the day this is a web application rolled out in a controlled manner (not much anonymous/public usage of AC) so speed, usability and intuitive UI are just sooo much more important than my being able to use a terminal to access it via lynx (or NS4). So long as it works with the major 3 (FFox, Safari, IE) its catering to 98% of your potential users.
I have to say, I fully agree with comments #2, #3, #4, #5, #10, #11, #12, #15, #16, #17, #18, #19, #20, #22, #23, #24, #26, #27, #28, #30, #36, #37, #39, #41, #43, #45, #46.
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…
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…
Like many people already noticed, it’s not hard to make code that work well when JS is disabled so activeCollab will work without JavaScript, but some advanced features (editors, pickers and other widgets that cannot be implemented without JS) will not be available.
Ilija,
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
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
Sounds like a good way forward.
I laghted a lot at that question “What sort of dictatorship world do you live in?”... hahahaha… I’m still laughing…
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.
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.
I support: usable when JS is disabled but require it in situations when you would end up with a crippled solution. Or just make JS a requirement.
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!!
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!!
You know what, I’m tempted to say make javascript a requirement simply because it would be unique and different.
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.
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.
New user here, (and I just gave aC 350 words in CPU Magazine – look in the July or August issue’s “Bleeding Edge” column), as well as a hardcore Treo smartphone user as well.
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.
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.
Make js a requirement, or even simpler make it Firefox 2.x and IE 6 compatible.
#9: Marc McHale said it all. It would be a shame for that project to take the wrong turn.
I just came here looking for a project management software, and I stumbled across this thread, and I wandered on over because I have strong opinions against Javascript. I’ll give aC a try, but if it doesn’t work without Javascript, I’m going to rm -f it and never think about it again.
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.
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.
javascript i think should be required. you end up watering down the features for everyone just to please a few.
take for example basecamp, im sure the ui would not be nearly as good without javascript and would definitely require more page refreshes.
take for example basecamp, im sure the ui would not be nearly as good without javascript and would definitely require more page refreshes.
Make JavaScript optional.
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.
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.
hard decision indeed… I don’t envy you. I would probably make JS required since I’m lazy, but there are those very rare moments when you’re in an internet cafe in Lagos and you need the basic html version to get something done. Also, some mobile browsers don’t handle javascript so well…. hard decision.
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…
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…
Bling sells… nuff said.
Make JavaScript a requirement.This is better.
Make it a requirement. Gracefully degrade if possible
No way around it, REQUIRE JavaScript, but be gentle.
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.
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.
I use lynx on my Tandy 1000RL to access activecollab. Please don’t use javascript because I want to use your product.
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.
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.
Haha. You got me scared for a moment ;)
I don’t have a problem making JavaScript a requirement, just make sure you test it with Opera too. Or at least to don’t lock out opera cause it’s not IE/FF/Safari.
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!
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!
Comments are locked. If you have something important to say about the issues discussed in this post please write at hi@a51dev.com.
Subscribe
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.