[1.35.0] Keeping home pages in sync
We've now got two home pages - one for the web site and one for the boost-root tree. We need to figure out how to keep the two in sync without totally duplication of effort. The problem is currently compounded by the boost-root tree home page using HTML and the web site home page using PHP. Every developer needs to be able to update "news" content on both home pages by adding entries in a single place, using a technology that does not involve learning a new markup language or installing a new tool chain. Updating content has to be stone simple, the way it was when we had a single web page written in HTML. Having a beautiful home page is useless if there is no practical way to keep content up-to-date. --Beman
on Thu Feb 07 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
We've now got two home pages - one for the web site and one for the boost-root tree.
What are you referring to as the home page in the boost-root tree? index.html in the top of our SVN trunk? If so, I was under the impression that it was supposed to go away in favor of the "one for the web site."
We need to figure out how to keep the two in sync without totally duplication of effort.
Getting rid of one seems easier ;-)
The problem is currently compounded by the boost-root tree home page using HTML and the web site home page using PHP.
Every developer needs to be able to update "news" content on both home pages by adding entries in a single place, using a technology that does not involve learning a new markup language or installing a new tool chain.
I don't know. Much as I am reluctant to do so, I'm thinking I probably need to learn PHP to be effective with the new site. -- Dave Abrahams Boost Consulting http://boost-consulting.com
David Abrahams wrote:
on Thu Feb 07 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
We've now got two home pages - one for the web site and one for the boost-root tree.
What are you referring to as the home page in the boost-root tree?
Yes.
index.html in the top of our SVN trunk?
Yes.
If so, I was under the impression that it was supposed to go away in favor of the "one for the web site."
Maybe the content is going to change drastically, but there still needs to be some form of index.html at the top of our SVN trunk. Otherwise offline access to other HTML pages within the tree is crippled.
We need to figure out how to keep the two in sync without totally duplication of effort.
Getting rid of one seems easier ;-)
If we get rid of the tree's index.html, how is anyone supposed to find the other HTML pages within the tree, particularly when offline?
The problem is currently compounded by the boost-root tree home page using HTML and the web site home page using PHP.
Every developer needs to be able to update "news" content on both home pages by adding entries in a single place, using a technology that does not involve learning a new markup language or installing a new tool chain.
I don't know. Much as I am reluctant to do so, I'm thinking I probably need to learn PHP to be effective with the new site.
I'm very unhappy with that. Are we going to effectively require every Boost developer become proficient in PHP? That seems like a non-starter to me. The alternative is to be dependent on a few people to maintain the web site. That creates a very serious bottleneck. --Beman
On Feb 8, 2008, at 8:13 AM, Beman Dawes wrote:
David Abrahams wrote:
I don't know. Much as I am reluctant to do so, I'm thinking I probably need to learn PHP to be effective with the new site.
I'm very unhappy with that. Are we going to effectively require every Boost developer become proficient in PHP? That seems like a non- starter to me.
I think it's a non-issue, for several reasons. There isn't all that much PHP on the new web site, so most web site updates will still be good old HTML. Even in those parts that are PHP, most updates just involve writing HTML, because PHP is just an HTML-generating superset of HTML, and in unless there's a PHP control structure around it, the HTML you write in PHP comes out as HTML on the other end. Plus, we're getting big benefits from the PHP that we are using, e.g., an RSS feed for news from which we generate the front-page "News" section without any separate steps. That kind of benefit, which keeps several places up-to-date when the same underlying data is changed, is worth a small amount of initial effort to save much more effort in the long-run. - Doug
Doug Gregor wrote:
On Feb 8, 2008, at 8:13 AM, Beman Dawes wrote:
David Abrahams wrote:
I don't know. Much as I am reluctant to do so, I'm thinking I probably need to learn PHP to be effective with the new site. I'm very unhappy with that. Are we going to effectively require every Boost developer become proficient in PHP? That seems like a non- starter to me.
I think it's a non-issue, for several reasons. There isn't all that much PHP on the new web site, so most web site updates will still be good old HTML. Even in those parts that are PHP, most updates just involve writing HTML, because PHP is just an HTML-generating superset of HTML, and in unless there's a PHP control structure around it, the HTML you write in PHP comes out as HTML on the other end. Plus, we're getting big benefits from the PHP that we are using, e.g., an RSS feed for news from which we generate the front-page "News" section without any separate steps. That kind of benefit, which keeps several places up-to-date when the same underlying data is changed, is worth a small amount of initial effort to save much more effort in the long-run.
The problem isn't the "small amount of initial effort". Rather, it is that important part of the web site content can only be updated right now by a very few people. For example, here is the section of the home page that reports "News": <div class="directory-item" id="important-news"> <h2>News</h2> <ul id="news"> <?php $_count = 0; foreach ( $_news->db as $_guid => $_item ) { $_count += 1; if ($_count > 3) { break; } ?> <li><span class= "news-title"><?php print '<a href="'.$_item['link'].'">'; ?><?php print $_item['title']; ?><?php print '</a>'; ?></span> <span class= "news-description"><?php print $_item['boostbook:purpose']; ?></span> <span class= "news-date"><?php print $_item['date']; ?></span></li><?php } ?> </ul> <p><a href="/users/news/">More News...</a> (<a href= "feed/news.rss">RSS</a>)</p> </div> I suppose if you understand PHP then this is crystal clear. But I don't, so will have to use SVN blame to see who wrote this, get them to add a comment pointing to some documentation on how to add/update the news items, and then cross my fingers hoping it really just does involve HTML that I can edit with my trusty old HTML editor or maybe my shinny new HTML editor. --Beman
On 08/02/2008, Beman Dawes <bdawes@acm.org> wrote:
The problem isn't the "small amount of initial effort". Rather, it is that important part of the web site content can only be updated right now by a very few people. For example, here is the section of the home page that reports "News":
[snip]
I suppose if you understand PHP then this is crystal clear.
I've added entries to a feed without reading a line of PHP.
But I don't, so will have to use SVN blame to see who wrote this, get them to add a comment pointing to some documentation on how to add/update the news items,
The documentation is at: http://beta.boost.org/development/website_updating.html#Feeds I'll go through the site and add appropriate comments. You wouldn't need to use SVN blame - an email to a mailing list would be enough.
then cross my fingers hoping it really just does involve HTML that I can edit with my trusty old HTML editor or maybe my shinny new HTML editor.
The entries are written in quickbook. Which is really easy to pick up. Daniel
Daniel James wrote:
On 08/02/2008, Beman Dawes <bdawes@acm.org> wrote:
The problem isn't the "small amount of initial effort". Rather, it is that important part of the web site content can only be updated right now by a very few people. For example, here is the section of the home page that reports "News":
[snip]
I suppose if you understand PHP then this is crystal clear.
I've added entries to a feed without reading a line of PHP.
But I don't, so will have to use SVN blame to see who wrote this, get them to add a comment pointing to some documentation on how to add/update the news items,
The documentation is at:
http://beta.boost.org/development/website_updating.html#Feeds
I'll go through the site and add appropriate comments.
Good. That will help.
You wouldn't need to use SVN blame - an email to a mailing list would be enough.
then cross my fingers hoping it really just does involve HTML that I can edit with my trusty old HTML editor or maybe my shinny new HTML editor.
The entries are written in quickbook. Which is really easy to pick up.
Maybe so. In the meantime, we need a procedure for those who don't use quickbook. --Beman
First, sorry for ignoring this for a few days... Been busy with other work :-\ Beman Dawes wrote:
Daniel James wrote:
The entries are written in quickbook. Which is really easy to pick up.
Maybe so. In the meantime, we need a procedure for those who don't use quickbook.
Quickbook is the only way to edit the news, history, and downloads. It's the way the web site manages to reuse the same content in various places (by showing it in different forms). Without using quickbook we would end up with a bunch of duplicated content which would quickly go out of sync. As has happened in the past. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
First, sorry for ignoring this for a few days... Been busy with other work :-\
Beman Dawes wrote:
Daniel James wrote:
The entries are written in quickbook. Which is really easy to pick up.
Maybe so. In the meantime, we need a procedure for those who don't use quickbook.
Quickbook is the only way to edit the news, history, and downloads. It's the way the web site manages to reuse the same content in various places (by showing it in different forms). Without using quickbook we would end up with a bunch of duplicated content which would quickly go out of sync. As has happened in the past.
Quickbook is fine as long as there is a way for non-quickbook boosters to get stuff posted. Maybe the procedure is a simple as posting it to the list with a [website] tag. --Beman
Beman Dawes wrote:
Rene Rivera wrote:
First, sorry for ignoring this for a few days... Been busy with other work :-\
Daniel James wrote:
The entries are written in quickbook. Which is really easy to pick up. Maybe so. In the meantime, we need a procedure for those who don't use quickbook. Quickbook is the only way to edit the news, history, and downloads. It's
Beman Dawes wrote: the way the web site manages to reuse the same content in various places (by showing it in different forms). Without using quickbook we would end up with a bunch of duplicated content which would quickly go out of sync. As has happened in the past.
Quickbook is fine as long as there is a way for non-quickbook boosters to get stuff posted. Maybe the procedure is a simple as posting it to the list with a [website] tag.
I'm not sure I understand what you want, and how is it different than editing the rather simple Quickbook text files. Note, if someone doesn't want to personally rebuild the web content that's based on quickbook that's fine. There are other people who will gladly re-build it for you. Also of note, is that it's *only* Quickbook and Python (and at some not too distant future Python will also not be needed) that one needs to regenerate the web content. There's no Boostbook, Docbook, XSLT, etc. involved. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 07/02/2008, David Abrahams <dave@boost-consulting.com> wrote:
I don't know. Much as I am reluctant to do so, I'm thinking I probably need to learn PHP to be effective with the new site.
I've done a lot of work on the site, and hardly touched any PHP. I think the only time I did was to configure a local server on my computer - and that could probably be improved (it probably should be, I keep accidentally checking in my configuration). Daniel
Daniel James wrote:
On 07/02/2008, David Abrahams <dave@boost-consulting.com> wrote:
I don't know. Much as I am reluctant to do so, I'm thinking I probably need to learn PHP to be effective with the new site.
I've done a lot of work on the site, and hardly touched any PHP. I think the only time I did was to configure a local server on my computer - and that could probably be improved (it probably should be, I keep accidentally checking in my configuration).
Yeah, I haven't figured out a way to simplify that part. But fortunately this only matters if one wants to see what the generated PHP will be. Most of the time editing and previewing the HTML doesn't need one to see the generated parts. And part of the hard part to make work for me was getting the non-dynamic versions of the pages reflect the real style even with the dynamic parts missing. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Beman Dawes wrote:
We've now got two home pages - one for the web site and one for the boost-root tree.
We need to figure out how to keep the two in sync without totally duplication of effort.
That's probably completely wrong! These two home pages serve different purposes. The content should be divergent. * The web site home page provides our World-wide Web presence. That's the place for news and other rapidly changing content, and as an introduction for first-time visitors. * The release home page is the gateway to the release, and needs content focused on that role. For the rapidly changing stuff, it should just refer to the world-wide web home page. I've done a first draft of contents for the release home page. If the contents are acceptable, we'll ask Daniel and Rene to integrate them into the current look-and-feel. Presumably the sidebar links will be similar to the current page. See http://mysite.verizon.net/beman/draft.html Comments appreciated! --Beman
Beman Dawes wrote:
Beman Dawes wrote:
We've now got two home pages - one for the web site and one for the boost-root tree.
We need to figure out how to keep the two in sync without totally duplication of effort.
That's probably completely wrong! These two home pages serve different purposes. The content should be divergent.
I can't figure out if you are responding to yourself or not :-)
* The web site home page provides our World-wide Web presence. That's the place for news and other rapidly changing content, and as an introduction for first-time visitors.
Yep.
* The release home page is the gateway to the release, and needs content focused on that role. For the rapidly changing stuff, it should just refer to the world-wide web home page.
Yep.
I've done a first draft of contents for the release home page. If the contents are acceptable, we'll ask Daniel and Rene to integrate them into the current look-and-feel. Presumably the sidebar links will be similar to the current page.
Thanks, I'll put this shell into the trunk now. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
Beman Dawes wrote:
We've now got two home pages - one for the web site and one for the boost-root tree.
We need to figure out how to keep the two in sync without totally duplication of effort. That's probably completely wrong! These two home pages serve different
Beman Dawes wrote: purposes. The content should be divergent.
I can't figure out if you are responding to yourself or not :-)
* The web site home page provides our World-wide Web presence. That's the place for news and other rapidly changing content, and as an introduction for first-time visitors.
Yep.
* The release home page is the gateway to the release, and needs content focused on that role. For the rapidly changing stuff, it should just refer to the world-wide web home page.
Yep.
I've done a first draft of contents for the release home page. If the contents are acceptable, we'll ask Daniel and Rene to integrate them into the current look-and-feel. Presumably the sidebar links will be similar to the current page.
Thanks, I'll put this shell into the trunk now.
Rene, any progress on this? It is holding up generating the first 1.35.0 release candidate. Thanks, --Beman
participants (5)
-
Beman Dawes -
Daniel James -
David Abrahams -
Doug Gregor -
Rene Rivera