Difference between revisions of "Talk:OWASP Initiatives Global Strategic Focus/website project"

Latest revision as of 16:19, 14 August 2016

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.
• As wikipedia is doing a very good job while using wikimedia, we should manage this as OWASP easily. Our content is very technical and less vulnerable against aesthetic discussions. In my opinion it is more important that the volunteers could use a standard tool to donate content. There should be easy to use example pages using templates and offer more pictograms to get a more common style guide. There may be a group that offers to upgrade the design of wiki pages.

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".

• I recommend moving away from a MediaWiki and instead to a Static HTML builder such as Hugo (https://gohugo.io/). This would allow decoupling the content from the platform and makes it easier for data reuse or migration in the future. Also, using a pure static site will make the site faster and less likely to be compromised since there is generally no server side code. I would further recommend managing the website using an open repository like GitHub. Hosting the raw articles in Markdown/reStructuredText on GitHub makes it easier to edit, collaborate, and comment. It also is inline with the open nature of OWASP and the content, making it easier for others to repurpose the content. Beyond the ease of providing collaborative version control, using something like GitHub specifically brings in the issue tracker and management features which are better than on MediaWiki. OWASP is also no longer responsible for managing accounts and related security; furthermore, a lot of people have GitHub accounts so this may result in more contributions. The downside is we would need a little more active management or setup continuous integration in order to take the raw code and upload to the live website. However, please note although the site is static, things like "Latest News", most recent articles, or other lists and cross references can be generated automatically. Some content like chapter events could be pulled in from a non-public repo or potentially from RSS feeds, etc.

  I think this may actually be plus since this will encourage more collaboration and reviews before any content goes live. Using a static platform also allows to embed more metadata, tags, etc. Multiple repositories could be used for projects, articles, etc and then ingested into one or multiple live sites. The main limitation with a static website is search. We could implement a backend to do search, but just as easy to have DuckDuckGo or Google index the site and do a site specific search box. I think most people search from Google anyway as their entry point.

  Alternatively, we could use a static HTML build and have the backend managing in something like contentful (https://www.contentful.com/), Prismic (https://prismic.io/), or even the Symphony XSLT CMS (http://www.getsymphony.com/).

  From a design perspective, because we have decoupled the backend from the frontend we have more design freedom. We know just have chunks of data that we put into a template language and can define custom html, css, cross linking, etc. We can migrate to another platform whenever we want or change the design, layout, flow, etc in an easier way. Once of the strengths of MediaWiki is multilingual, but it is possible to do this with a static website builder as well (not necessarily an out of the box feature, but I have done it with Hugo specifically). The content could also be ingested and processed into Apps, testing tools, etc. very easily because the raw content is publicly available and could either be scrapped or someone can just clone to git repo.

  We still may need other systems when we need interactive components, but better to use the right systems for the right purpose then try to make one system do everything.

  In terms of gamification, I am not sure if people really care about earning OWASP points, but a lot of people do take pride in showing GitHub activity or would include their GitHub profile on a resume. By going on GitHub you can leverage an existing platform that already has statistics that people may already use to show off.

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 needs (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: Let's try to create and test a new 'Main Page' here. There had been even developed 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 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 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 approved 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...