View source for Talk:OWASP Initiatives Global Strategic Focus/website project

== Thoughts on look and feel ==

The Needs Assessment report has a good analysis of the current web site and provides a lot of valuable ideas for improvements. The mock-ups mostly look attractive. However, I disagree with some of the underlying assumptions:
* Wikipedia-style is derided. However, this style is wholly appropriate for the OWASP style IMHO. The OWASP web site could do worse than emulate Wikipedia '''more''' faithfully. Run towards Wikipedia, not away from it!
* The (ISC)^2 web site is put forward as a style to aspire to. I beg to differ: the current OWASP web site looks a lot more attractive to me than (ISC)^2's. The former is much easier on the eye. (ISC)^2 may draw attention through the use of striking colors and more graphic material. However, no additional useful information is conveyed. The net result is a feeling of weariness: my brain has to work hard to take in all these stimuli and I get very little in return. Remember that web sites are not competing for attention like billboards: unlike billboards, you visit web sites one by one. A good web site conveys its message while minimising collateral damage through information fatigue.
* Agree with both of the above. ISC2 is not a "competitor" and whilst the report has much to offer, focusing on ISC2, ISACA, ISA for comparisons seems a bit lazy. These other organisations are not like OWASP in terms of objectives, audience or membership. I remember being asked during an interview for this "shouldn't OWASP be the primary source of information" and I said no, OWASP's role is to promote application security - not promote itself. AppSec info appearing on other websites is a win - not a negative.
*  The importance of the (ISC)^2 website is not that (ISC)^2 is a direct competitor or the colors they used but that they inhabit the same "space" as OWASP and that their decisions about organization make their website easier for new people to use.  
*The suggestion is not necessarily to do away with the wiki but to clean it up and change a few key landing pages to be easier to follow.
* On p28 of the report, there is a recommendation to make the projects more consistency. I disagree, let projects lay out their content however they want - the audiences vary massively, and projects vary a lot too. OWASP is not ISC2 and I suspect never wants to be. ISC2 keeps getting used as an example - what about other community sites rather than commercial sales-orientated vendors like ISC2? At least OWASP has a memorable/writable name.
* Agree, a breadcrumb trail mentioned on p31 would be useful, but is still a challenge to define what the hierarchy might be
* Peer analysis on p32 is flawed. The organisation mentioned are not peers.
* Fascinating, p37 says "OWASP has the highest Alexa ranking"... err so why do we have to change so much?
* The "bounce rate" is mentioned as a negative here but fails to understand how some people use the site. The high number of "single page visitors" was also lauded by the report's authors as awful during the telephone interview, but they did not realise that some people use OWASP as a reference document, and use Google to search for "XSS cheat sheet" for example, then go to that page, use the information and then get on with their lives. There is no analysis of robots anywhere in this report, so the analysis of information presented about visitors is guesswork.
* The wikimedia style is arguably very good for ''some'' things but not others. I think the confusion is between consumers and contributers. Consumers want a site where navigation is easy and hierarchy is obvious, contributers want something where changes can quickly and easily be made and discussions had interactively. Remember that wikpedia encourages citations to backup information, something that is much less common in Development, especially AppSec where the "right" answer is often opinion rather than fact.

== Thoughts on Platform Selection ==

* p48 states there are two purposes for the OWASP website.... (1 Organisation visibility and membership promotion/participation and 2 Improve application security visibility...). Although this is stated within what is called "Option A", it seems to apply to all three options. But more importantly, "Organisation visibility and membership promotion/participation" is not one of OWASP's objectives, values, purposes or principles. Who said that self-promotion is one of the website's purposes? If the only purpose is instead "Improve application security visibility...", then the arguments for the 3 options need to be revisited e.g. the report says "These 2 purposes are at odds with each other".

== Thoughts on Information Architecture ==

* The proposed top level navigation on p50 is inward looking, and doesn't consider the site's audiences and their needs
* The "OWASP Podcast" is no longer updated - it is called "OWASP 24/7"
* The proposed design for the home page on p53 is not compatible with OWASP's activity level and ability to generate content frequently, specifically:
** Blog post frequency is typically 2-4 per month which would give the impression not much is happening
** Not sure how "latest news" is different to what appears on "blog" or "podcast" or "events" - the Global Connector is the most regular OWASP output, but that content also appear on the blog and OWASP 24/7
** OWASP 24/7 frequency is quite variable. Excellent content but old dates might put people off
** The events diary has never represented all the chapter and other local meetings going on, and therefore suggests OWASP is not active in many places when it actually is - most events listed on the current home page calendar are not OWASP events, but security sector events
** "AppSec feed" hasn't existed for many years now - it was extremely good at the time, but a spot on the home page with no content will look terrible
* The earlier section of the report suggests that most visitors want the Top 10, ASVS and Cheat Sheets. they are not mentioned anywhere on the proposed design
* The main page needs the most effort; It should be user oriented, mainly to our visitors/guests not to the insiders!
** The main page and the following landing pages should pick up the users by their <b>needs</b> (I'd like to ...); Please keep in mind that our visitors do not know the internal OWASP wording (e.g. Project, Chapter, ...)! I do think that is a better alternative than to do it by their roles. Finally it should produce less redundancy.
** In 2014 there had been already a task force to get a better home page and there is still a simple mockup for this structure: [[:Category_talk:FIXME | Let's try to create and test a new 'Main Page' here]]. There had been even devoloped some nice pictograms (are they still available)?
** A guest should be able to find the most important assests from OWASP via the main page without any search engine. He should be directed to the right landing pages where he can get the information he needs. Additional he should get easily information about OWASP and how to get involved.  
* The global navigation should be altered, too. The drop down navigation should primarily direct to the main pages and the landing pages.
* Project drop down on p56 is OWASP-centric instead of audience-centric - who cares how OWASP categorises its own projects? It's important, but shouldn't be the prime way to find information.
** As the main page the following landing pages, e.g. projects landing page (p55/56) should oriented by the needs of our guests.  
* Project page mock-ups lack inspired thought
* How is "recent activity" on the projects page updated and who does it?
* The project wiki article page suggestion on p57 looks boring, and throws away lots of content on many project pages
* Breadcrumb trail and other things were mentioned as missing in the report discussion, but lots of those recommendations don't appear in the proposed designs - why not?
* The mockups and comparisons to "competitors" are possibly contentious because the description is not abstracted to a high enough level. For example, it should not be a case of ISC2 does navigation this way and they are ''competitors'' so we could/should do it this way or even 'their way looks better'. The correct abstraction is ''what is it about OWASPs navigation'' that is not working and does the way that ISC/others do navigation solve the problem. This is important because there are several ways to achieve what you want as long as you are asking the correct question.

== Thoughts on Back Office and Infrastructure Architecture ==
This should certainly be a priority. It is difficult to volunteer for projects and efforts since work needed is not centralized. Additionally, communication seems to always go out of band to email which reduces overall teamwork and transparency. While the groups are very successful, we are losing volunteer work due to an inability to locate it.

== Thoughts on Gamification ==

* The pool of active contributors is not large enough to make gamification meaningful

== Thoughts on Features and Release Roadmap ==

* The report says on p64 that "[content on] MediaWiki older than 2 years and have not been accessed frequently should fall under the archive". No thanks, the test should be whether the content is still relevant or useful. Not sue the report authors understand what OWASP's mission is about.
* "Automated scoring and badging" - no thanks
* there is a big risk of 'false positives', e.g. formal reviews of a project page are not representative for the activity of a projects, especially of a documentation project providing wiki pages. 
* Projects and wiki pages are assets of the OWASP community they should be supported and nurtured: there should be a 'promoting' philosophy:
** there sould be a some 'official caretakers' that contact the main editors/project leaders and organize support instead of archiving content 
** there could be a basket of practical useful help where wiki editors and projects could look what is offered
** there could be a 'market' for small volunteering, where pages could be fixed or wiki editors/project leaders could ask for dedicated help
** if the page contains <u>approved</u> outdated content that could not be fixed the trustworthiness should be reduced before it is archived
** archiving should be the ultima ratio, a comittee should decide transparently and publish lately archived content and a reason why this was necessary. 

== Thoughts on Search Functionality ==

* Did I miss something - "search" doesn't seem to be mentioned in the report's recommendations, or "features and release roadmap"

== Another topic... ==