Furthermore, apart from the JS question, we should discuss in the community, which type of market we want to approach. Do we still want to address a wide market and do we still have the goal to offer an all-inclusive web tool for all kind of use cases and all kind of various user groups? Do we still address the professional market as trying to get a stable system with robust fallbacks for special situations? Do we focus on the professional market and do we respect, that we need to support our self-employed consultants to get work and to get companies into the project who can co-fund the development? Or is Tiki more like a hobby project, where single coders commit stuff to their own needs and spleen and can just ignore the needs of other community members who partially indeed do not code themselves, but commit other values to the communities and who depend on Tiki generated revenues or who maintain NGOs’ web projects based on Tiki?
- In April 2015 we are saying we have to decide if the Tiki project accepts that there are considerable numbers of users on the Internet who decide to browse the Internet with the no-script option active in their browsers and if the software Tiki shall allow those users by default to access content and basic editing on average (not massively customized) Tiki websites.
- We have to decide if we want to seize the opportunity for web developers, admins and web masters to address no-script users as considerable target group of their web publications and to let them at least contribute in a basic manner on Tiki based collaboration websites like intranets.
- We have to decide whether consultants can offer their customers no-script access to Tiki content or not.
- Please mind, that if a user uses no-script or switches JS off in his browser, he cannot at all browse a Tiki website right now and he cannot even print a wiki page or find the necessary content in a menu.
Do we really want to leave those people out and just ignore them as potential users? Are we really so good, that we do not need them? Do we really know for sure, that those people and the NGOs who deal with them as target group are such a small irrelevant group? Are all the Occupy, Blockupy, data-protection, anti-data retention activists, hardcore administrators, Snowden sympathizers, NSA citizens etc. irrelevant small groups, which should not be addressed by Tiki and all in general and by our consultants in specific?
This is the question here - and again: tech-wise we are talking about robust fallbacks for navigation and basic editing, not about advanced functionality. Do we really hide access with JS and obtrusively force users to use it only to be able to READ our content or to EDIT A WIKIPAGE ? Is that the way we want to go?
- Toolbar & Smileys rely on JS, so should not appear
- Help should continue to be shown at bottom of page (like in 3.0)
- Forms submitted by JS onchange event (e.g. theme switch) should always display submit button with at least “Go” when JS is off
- Done: theme switch shows “Switch” button when JS is off
- profiles won’t work
At 20 April 2015 Gary, Amette and Torsten agreed on a plan of action and to suggest this as a concept to the community
- 1. Create a minimal set of rules that helps grasp the core concepts of non-JS, like “keep the information accessible”
- 2. Codify that.
- 3. Implement across the board for Tiki 15 LTS
Please add your name to the plugin proposal to mention, if you agree to that plan or you are undecided or opposed.
- barrier-free websites
- blind people (see report and discussion at item5682
- security-focused users
- Tor Browser Bundle has ))NoScript(( installed by default
- Restrictions imposed by the owner of the client computer
- Public computers on US Army bases
- machine readable sites and search engines
- legal obligations
- Tiki philosophy: make things optional
- respect the environment
- people might deactivate it or use noscript plugin (e.g. Firefox)
- desktop ressources are wasted, powerusers with many browser windows and many tabs
- NGOs don’t like it
- Tiki admin access should be easy
- usage of text-based browsers, e.g. lynx
- security, software bugs
- hinders progress and modernization of Tiki with features that are universally popular
- modern touch screens and dropdown menus
- better functionality
- better user experience
- support Ajax and Tiki services
- burden on code and volunteer coders - more difficult to maintain and understand code
- Results in significant duplication of code in some cases
- cost/benefit - benefit to small user set has not yet been proven to outweigh the cost
- wisdom of “stuck-in-time” approach to JS issues is questionable and not accepted by many, including in the Tiki team
- Other potential solutions not explored, and exploration is discouraged
- Respect the environment which includes those who disagree with the “stuck-in-time” approach
- danger of making the most commonly used functions the most backwards - a significant overall negative for Tiki’s appeal to users
- May result since coders will be less likely to enhance or modernize with JS-based enhancements in areas where JS must be optional
- Restrict optionality requirement to discreet actions where considered absolutely necessary
- Optionality only to be considered for most basic features and the most basic actions within those features
- Optionality not required in following areas (not an all-inclusive list):
- Admin areas (i.e., anything requiring tiki_p_admin_xxx or tiki_p_feature_admin permission), any feature where Ajax services are used (e.g., Trackers), Perspectives (requires jQuery UI), Spreadsheets
- Basic features where optionality should be considered:
- Wiki, File Gallery, Article, Blog
- Basic actions where js should be optional within the basic features: