Proposed new FreeBSD.org website design

This has already been mentioned in the thread below, but it was suggested that it should be a separate discussion (makes perfect sense), so I may as well start it. Someone also mentioned discussion on a mailing list but I can't find that?

https://reviews.freebsd.org/D3934
http://www.freesbd.org/
https://forums.freebsd.org/threads/the-actual-freebsd-logo.53849/

Personally I'm not a fan.

I like that it's responsive, as well as thinking that being responsive to tablet/mobile/etc is one good reason why a new website should be considered.

However, I think it's a bit *too* sparse. There really isn't much to it, and a lot of what is there could do with polishing up a bit. For some reason the languages always split across two lines for me, the footer looks like no real thought has been put into the layout - there's just a big block of links, and why is the logo 5 times the size of any logo I've ever seen on a website before? Also the search could do with spacing away from the menu on the smaller layout, and the same for the content and side menu on other pages. All in all it has a long way to go for me.

This may be a contentious point but I think FreeBSD is a great project with some global-scale users. I think if they're going to rebuild the entire site, they may as well try and actually make it look like an enterprise grade product, and try and give the same sort of impression you get from sites like suse.com or ubuntu.com. I've no doubt some people on here will jump in to tell me how much they hate both those websites and anything like it, but to me the new design still looks like a pet project compared to them.

I would like to try myself but I've always been more of a developer than designer. Unfortunately I get the impression the people behind the existing website, and this new design, are probably in the same position. Maybe it needs a completely different tactic and the Foundation should consider hiring a designer to draw up designs (no code literally just mockups)? Completely unrelated but I believe Roundcube just hire an external designer for their web interfaces and their existing interface was great back in the day (looking a bit tired now) and the new Roundcube Next interface looks awesome.

Or course it's probably mostly a waste of time. The entire existing system is built on some giant XML/XLST templating/automation system I believe (my idea of hell). The people behind that aren't going to be the ones making a new website, and anyone from outside is going to struggle to create something that integrates perfectly with the existing infrastructure.
 
The existing website does a lot of things, and not all of them are obvious. Of course, discussions of a replacement are often diverted by what it should look like. That is really one of the easier issues. The more difficult ones are documenting everything the existing site does, and having viable replacements for all of that functionality.

To be clear: I'm a documentation committer, a member of doceng, and was involved with the talks about the proposed new web site since 2014. It was not something I particularly wanted to do, people asked. The most recent discussion of that proposed site took place in several different locations, not all of them public. It was a largely one-sided and unproductive discussion.

To replace the existing web site successfully, it must first be fully understood. A lack of understanding of legacy systems is one reason so many IT projects fail.

The web site is part of the documentation tree, and can be checked out and built locally. I recommend this as a first step to understanding. See the FDP Primer chapter on that for instructions on building it. See the Quick Start to get a documentation tree checkout.

Some of the site is hand-written HTML, some is HTML generated from XML source documents. There is some CGI. It is not a CMS, no database is involved. It is more like the new trend of static site generators in how it works.

The CSS is available in en_US.ISO8859-1/htdocs/layout/css.

There are many areas where it could be improved. For example, the quarterly status reports depend on XML documents submitted by people who generally do not write those type of documents. This could be made easier for them by using one of the more common web markup languages.

To me, the CGI portions are a weakness, requiring a web server and additional code to work. Can they be reworked or eliminated to remove that need? Probably.
There are portions where people are expected to maintain sections of raw HTML.
I would prefer to see more separation between content and presentation. We have a provision for "Styles" in these forums so that people can choose how they look. Why couldn't we do that for the main web site also?

The look of the site can be drastically changed just by editing the CSS. I know this for a fact, because I recently changed only the parts relating to font size and screen width and people thought we had redesigned the site.

If needed, new images and possibly Javascript could be added. The question then becomes whether the way the site is generated needs to change, rather than just the way it looks.
 
Or course it's probably mostly a waste of time. The entire existing system is built on some giant XML/XLST templating/automation system I believe (my idea of hell). The people behind that aren't going to be the ones making a new website, and anyone from outside is going to struggle to create something that integrates perfectly with the existing infrastructure.
I disagree. We doc people are the people behind it, and we update docs and the web site all the time. We just don't throw out working build systems until there is a viable replacement.

As far as integrating with the existing infrastructure, agreed to some extent. But that is always the case with legacy systems, and why it seems so simple to just throw it all out and replace with a new, clean implementation. Until you learn about all the stuff the old system does...
 
Wow.. I had no idea the site was so monolithic. And XML? Ugh..
We must have different definitions of "monolithic", because I just posted about how at least three different systems were used. That does not include the documentation, which is in DocBook.

The web site is part of the documentation tree
Why is this?
I can only guess that when the original source, ports, and doc repositories were created, the web site seemed to go most logically with doc. Much of the web site contents come from the documentation tree anyway.
 
Obviously I'm not suggesting that the entire current management system be dropped. Just that trying to get a new website, especially one developed by people who haven't had historic involvement with the site, integrated with the existing infrastructure is probabaly going to be the main stumbling block.
 
Can you explain that? How would the site not use a web server?
Sorry, that was not clear. When you generate the web site locally for editing and testing, all the generated HTML files can be viewed just as static files. Nothing extra is needed but a browser. However, anything provided by a CGI script cannot be tested unless a web server is installed and set up for CGI.
 
I think that's one thing most people would agree on (although probably not lol). It makes far more sense for the FreeBSD website to be pre-generated, then consist entirely of HTML documents, than have some overly complex dynamic website that needs a web server, or even worse one of those fancy ruby/Python/insert-new-language-of-the-week deployment systems just to test with.

From a sysadmin point of view, hosting and running the actual site would be much more predictable and easy to manage if it's static.
 
But seriously XML sucks :D

I remember when it first became popular and was going to revolutionise the Internet. Everything was going to use XML and a simple text format was going to change the world. I even bought into it and used XML as the config file format for one of my projects once. Just made the config file 10x bigger than it needed to be, more hassle to edit, and needed expat + a bunch of dependencies installed to parse it... Unfortunately for Microsoft they seem to have brought into it a bit too much for their config format as they use it everywhere. I think their parser is pretty efficient these days though and at the least it means they can create universal tools to generate, edit and validate configuration files against DTDs, etc.

It was supposed to be a simple format that a CS graduate could write a parser for in a couple of hours. The ability to parse it with any simple code died out almost immediately when they started bringing in namespaces and every other kitchen sink feature it now has.

I also used AJAX once. I think that was also Microsoft funnily enough who decided XML was a great format for browser data interchange and coined the acronym. I believe they first used it for Outlook Web in IE. Pretty much the first time I tried it I realised how ridiculous it was spinning up an XML parser instance in the browser just to parse a bit of data from the server. Just sending a simple string produced about 5 times as much XML compared to just using plain text or JSON and performed like crap.

Of course I appreciate a lot of legacy (and new) systems use XML, and make very good use of it. I believe there's a pretty "enterprise" document management system (docbook?) based on XML or similar that probably does all sorts of clever stuff (In fact I seem to remember some document format using an older, more complex ancestor of XML?). Probably why FreeBSD docs are all XML based. I also fully agree that the existing FreeBSD doc system needs to stay as it is, and that any new website needs to work with content generated via the existing infrastructure. I'm mostly being awkward but await the flaming :).
 
There's nothing wrong with separating content and structure from presentation and formatting. XML and the related technologies just get it wrong by insisting on a clumsy format that nobody wants to edit directly.
 
In all fairness, for the FreeBSD website and associated data (handbook, etc), what else is there other than XML that can be used to create text based data documents, which can be source controlled, then rendered into HTML, PDF, man pages or whatever other format you might want to view the data in? Off the top of my head I can't think of anything decent.
 
As said earlier, we could generate the web site with something else. But first, let's say this:

Here is the generated HTML of the site. You have complete freedom to do whatever you want with the CSS. It is more complicated to change some of the HTML or the make(1) system, but still possible.

Given that, why even worry about replacing the build system? What changes to the site would require that?

This is the opportunity for anyone who does not like the web site: check out the doc tree, rip out the CSS, and do it "right". Or just modify the existing CSS to make it better. Submit the diff to reviews.freebsd.org, and please be sure to add me as a reviewer.
 
I'm probably being a bit of *** just complaining about things and not attempting to do actually anything but I really don't have time to work on it. Maybe if I had something more usable than a laptop at home but unfortunately I don't at the moment.

I just thought that if this is a serious enough attempt to update freebsd.org that it has a website, GitHub and has actually been submitted to reviews.freebsd.org, that there should be a thread on here for people to discuss it, even if it has kind of veered away from talking about the design so far.
 
Sorry, wasn't calling you out or anything. People complain about the web site, and rightly so. A few notes like these might prevent hurt feelings when someone works hard on a replacement that we might not be able to use, and now seemed like a good time to give some notes on how the present site works.

And I'm serious about the CSS rework, I would love to see a rework of the site. Or several.
 
And I'm serious about the CSS rework, I would love to see a rework of the site.
The reason I asked my questions, and visited the github site, was cause I was going to see what was involved with the started rewrite by Claudia. I own a web dev company, and we do pretty good, but it's smaller sites in the entertainment and restaurant sectors but none as big as what FreeBSD is if you include everything. Not that I'm afraid of that but it's a matter of not knowing how far the rabbit hole goes and "Why are you working on that when you should be working on this?!!" I'll hear, I'm sure.

I have one project I'm trying to finish. The wife is going out of town to see our son tomorrow. I'll see if I can get to it.
 
The existing website does a lot of things, and not all of them are obvious. Of course, discussions of a replacement are often diverted by what it should look like. That is really one of the easier issues. The more difficult ones are documenting everything the existing site does, and having viable replacements for all of that functionality.

......

To replace the existing web site successfully, it must first be fully understood. A lack of understanding of legacy systems is one reason so many IT projects fail.

Bulls eye. From my view point and use: I think the site is pretty darn good as it is. Please ask youselves, what is the problem you're trying to fix. Might see like a silly question, but it can bring a lot of sanity to the discussion.
 
From my point of view, the web site has a lot of informations about the project and developers, perhaps not all 'important' pages are accessible from a menu o sub menu (on the pages) but mingled with the text. The forums site is (at the time) a bit slow repect to phpBB and vBulletin (vBulletin was very fast). Nothing to blame to, the bandwidth grows and code follows (and I only use the 1% of the features).

Aestetically, it's another thing, I do not really see as it should, due to network filters. It's not attractive as someone would, it's an OS web site, after all.
 
I think the site is pretty darn good as it is. Please ask youselves, what is the problem you're trying to fix.
I don't want to get into a point-by-point discussion of that now but there are a lot of design issues going on; some of them not so obvious unless you know what to look for. We had a local ice cream maker that used to advertise, "It's a subtle difference that makes all the difference."
 
The top of my list would be organization/usability issues. Things can be hard to find, and every so often people who have been using the site for years will discover a section they never knew existed. It is also somewhat complex, with multiple ways to get to the same place. The web2py page is an example of better organization and simplicity, in my opinion.
 
I don't think the website does a good job in the way it advertises what FreeBSD can do, what it offers, etc. This may sound dumb but I'd like to see more graphical representations than just a huge wall of text and libraries. If I were a new user, and I saw something like "hast(8) or jail(8)", then a bunch of uber-computer-science jargon, I wouldn't know what to think. It's easier to get a point across for the wider audience with "laymen" material. The Ubuntu website does this very well.
 
I think the FreeBSD website does it very well. On the Ubuntu page are lots of images and nice photos, the website looks consistant and so on. This is really advertisment. Many people will like it. On the other hand on the FreeBSD start page I have everything on one screen. Nothing is overloaded. It is clear. This is some consistency with FreeBSD - if I am allowed to say so as a newcomer. I do not write this to attack anybody. Usually advertisment requires to define the target group. I think it can be a good idea not to follow the modern style. It can be better to be distinguished from others.
 
Back
Top