Forum OpenACS Q&A: New OpenACS website - Please test!

Also, bboard URLs should automagically be redirected to the appropriate Forums URL due to some magic index.vuh incantation that Til has come up with (cool stuff!)

I couldn't find *this* forum over there, popping in to read in a couple of them I found the extra page complexity unnecessary, and forum pages seemed to load quite slowly compared to this server.

Van

http://dev.openacs.org/forums/message-post?parent_id=34917
--> http://dev.openacs.org/forums/not-allowed

http://dev.openacs.org/forums/search gives me a request error (bboard search from http://dev.openacs.org/forums/forum-view?forum_id=14013)

Can we also post test items to news, general-comments etc.???

P.S. It already looks great!

You ask: Is there a reason why people are still using Netscape 4.x?

There's probably more than one reason...

In my situation, the company operates on a quasi-upside-down technology deployment principle, where the faster computers go to those with the least computer experience --except when client projects demand commandeering the faster machines. Those of us with more computer experience get to use slower (older) computers because we can manage the technology more effectively, thereby extending the value/use of the resource. NN4.x runs faster than 6.x on the older machines. I'm glad I'm not stuck with using lynx all the time. ;)

For the record, one of the machines I use has a black and white monitor on it... thankfully the new design has adequate contrast for 256 grey scale.

On one of the color monitors, the gamma is very low, showing again how important contrast is for viewing websites on poorly configured/mismatched equipment.

These systems are constant reminders of the variations in browsing configurations one can expect to need a website to adjust to --especially for an open community oriented website like openacs.org.

In the future, I'd like to see a reversal in the text background colors, where the whitespace is off-white/grey, and the main text body areas are whiter (ie. brighter).... to highlight the main reading areas... but I'm not complaining. The priority is speed, function, and a new look (which I like, too).

An afterthought...

Instead of putting an   into each blank TD tag, we could put a statement at the bottom of each page that states:

This website best viewed by coming over to one of the developers locations and viewing it on their screen. =)

NN6 on Mac doesn't format the middle of the page very well either (it runs over the login box). Yet on NN4, there is a circa 25% width space between the login-box and the middle body text (with CSS active)! I will see if I can create a stable html version in the spirit of the current design...

This happens as soon as the width of the browser window is below a certain value. The example above was generated with a width of 800, a reasonable value I guess. I tried to make one tr per input field, but that does not change the behaviour. Setting the size of the text input fields to 14 makes it look good at browser width 800 but too small when wider, there must be some other way to solve this that I don't know.

My solution would be to leave out the login box at all, IMHO the link in the header is sufficient and as soon as someone wants to do something restricted there'll be a redirect to /register anyway. But since the box is on the site I guess there has been an agreement that we want to have it.

And something else: please rename the Main Site instance, because it shows up in the title tag of the front page.

Are the mapping tables migr_message_map and friends in place and filled with the right values?

I like the sound of that!

You can work on the header. Torben is welcome to work on the "main content" text section. And I can just relax (for a change).

Well I can try to make the blue lines in the boxes look good in NN, actually. 😊

Let's get to work,

We will be using the data in this database so I didn't want test posts to clutter the bboards.

There is a "Test Forum" if you would like to test the functionality of the new forums package.

We have sped up the forums index pages considerably with Roberto's applicaton of template::paginator so it does not load over 2000 threads on the first page.

There is still an issue on viewing one thread that is slow.

If anyone has a chance to check the forums code on postgresql feel free to offer a patch to speed it up.

Also, anyone who wants to see the code can checkout
openacs.org-dev from the OpenACS CVS repository.

I disagree with the suggestion that it isn't all that important since most users won't see it.  NEW visitors to the site have not yet registered, and they're MOST likely to be turned off by an ugly site design.  If we can't fix it easily, how about replacing it with a "register now!" button, similar to the "Unleash OpenACS" graphic?

One other issue with the first page:  The blurb about "why not mysql" is great, except it stops in mid-word.  Truncation at a word would be nice, as would a [more] or [read more] link at the end. **  I found myself wondering why it cut out in the middle, and how I could read some more about it.  Only THEN did I realize the link was up at the very top of the article, which I had to scroll to reach in a small browser window.

** alternately, cutting this blurb down to one or two sentences would also be reasonable.  The blurb is maybe a little bit rant-like for the front page anyway.  Let's make our first-time visitors click at least once before they discover we've got strong opionions, maybe?

I was worried that the image studies looked overwrought, but this is quite nice.

Maybe try to move ad_header and/or context_bar up somehow so that the header uses less vertical space overall? I'm not entirely happy with our solution, but see if there's anything worth stealing from my.brandeis.edu or our coming redesign at http://sandbox.brandeis.edu/ and we'll do the same. I do believe your CSS is a heck of a lot cleaner than ours.

(Thank you, thank you for keeping :link and v:link usably colored. This is a battle I seem to have lost locally.)

CSS, Tables, Forms, and Netscape 4:

The only CSS safe with tables is color and font-face. Hopefully you won't have to resort to the evil, evil Netscape4-specific .jss that our designer inflicted on http://www.brandeis.edu/its/

Good you don't try to set line-height. It does *very* bad things to tables and forms in Netscape 4. Table elements actually disappear.

The logo has changed, so I haven't made any final adjustments to how the bottom of the logo integrates with the rest of the header table.

The image links and css file url have lost their file tree references for this version (but can be added without too much difficulty).

For future reference, if this design stays, we might want to convert the header links to graphics representation (with img alt tags) for visual consistency, and to simplify the CSS sheet. This will add further compatibility to viewing from NN4 and other browsers that lack the latest features...

Here's the file urls for direct download:

http://dekka.net/newbuild7.html http://dekka.net/main.css. Sorry I'm not in a position to formally help with creating the adp files etc.

I just updated my openacs.org-dev unfortunately I have an old copy of the db dump.  Can someone point me to a more recent dump?

At www/templates/widgets/navigation.adp you can remove the "width=10%".  This will spaceout the navigation links evenly.

Carl,

Thanks for doing that.

Here is how we do it, and I know you know it can be done this way. But it might be news to someone else:

We have implemented the different boxes as <include> "widgets", which is made up of tcl/adp pairs that perform specific tasks like showing a search form or a "recent postings" listing.

They are called from a central adp template or the default master, for instance...
The widgets that are supposed to have a pretty box surrounding them in turn call in a "box-master template" by including a <master src="box-master"> at the top of the adp page.

It's very easy to make a few different box templates and pass various parameters to them to control the title, color, etc.

For example:
<include src="/widgets/postings" title="Recent Postings" bordercolor="#cccccc">
The widget's adp page passes the parameters "title" and "bordercolor" along to the "widget template" (box-master.adp in this case).

At the top of box-master.adp:

<master src="box-master">

<property name=title>@title@</property>

<property name=bordercolor>@bordercolor@</property>

<multiple name=recent-postings>

  <li>@posting_title@</li>

</multiple>

I am curios to hear if there are benefits of creating custom templating tags compared to this method

In all browsers but Netscape 4.x, that is...

It's become evident that this particular browser was not designed to handle CSS - and perhaps not HTML either - in a comprehensive way. If you ask me, I'd have to say that Netscape 4.x is a non-functioning browser by today's standard. Which is not such a disaster since, as the lean alternative needed by the Linux world, it has been replaced by Opera.

It boils down to this:

Either we do not bother to adapt to Netscape 4.x (more than we have already) or we do indeed bother (make the needed effort, it would be called in that case).

Not bothering would mean that we are done. Bothering would mean that we'd have to take a step back from today's CSS-based centralized design philosophy to yesterday's HTML (<TABLE>) based decentralized ditto. We still wouldn't be able to make the design look perfect on Netscape 4.x, but the main content would be forced to behave.

My radical view is to leave the past behind - and Netscape 4.x is a thing of the past. As I suggested - correct me if I'm wrong, because my entire argument is based on this assumption - no Netscape 4.x user is left without an alternative. Free lightweight browsers are still around, only now they have evolved to fit present expectations.

I'm not suggesting that we sacrifice the Netscape 4.x users, thus, I'm only suggesting that they sacrifice their browser. Am I being unrealistic, or even too realistic? Or just lazy? You decide.

http://www.richinstyle.com/bugs/netscape4.html
http://www.richinstyle.com/bugs/netscape4b.html
http://css.nu/pointers/bugs-nn.html

The web site and the toolkit are two different things, but the web-site will reflect badly on the quality of the toolkit, if we don't make it work well for the netscape browsers.

Greenpeace, for instance, has that as a requirement for user-visible pages (with Mozilla/IE being acceptible for admin/content production pages as they can upgrade their staff's browsers).

So I'm with Simon and Dan, if we want to look like we're providing a serious web toolkit our website needs to be functional and look "OK not perfect" with 4.x.

Speaking in favor of the CSS method is its simplicity, centrality, and rendering speed compared to the old method of working with HTML tables. Plus, unlike HTML, CSS seems to be interpreted in much the same way by all modern browsers; it's quite a lingua franca.

Arjun has brought to our awareness that there are workarounds that may help Netscape 4.x to understand CSS better. Hence he's implicitly saying that we should go with the CSS method. Dave is more explicit about this. What is your opinion?

Right now the CSS file has been tampered with and temporarily messed up, so please do not base your judgment of a CSS based website on what you've been seeing today. There is great room for making the browsers of the world quite happy by shaping up the CSS file.

Improving the css is something that can be done continuosly from now on til forever. Scrapping the CSS logic in favor of the HTML logic will have to be done right away. Do we want to do that? I say no.

I think you can use css quite effectively without resorting to throwing out a major browser for the Linux crowd. I posted one box previously in this thread that uses css (http://stellardata.com/ms/form.html). The problem here may be the use of positioning in css. The forums page is really messed up.

Or we could take the tack of Yahoo mail and just require IE6 so we can include na MS Word looking widget to post to the forums. :(

If the designers don't have a Netscape 4.x browser to test what can work in css, that might help.

Also, the bottom corners of the boxes now look funny. There is a sharp transition inside from the side of the box to the corner, then a hollowed out corner. For some reason the top articles on the front page take up 3-400 pixels, while the lower articles are squished into about 150 pixels of horizontal space. There are also a lot of spans with the same id. I thought ids were supposed to be unique. Some have id=title and others id=description.

I'm sorry, your previous post indicated you were done. I retract my comments. Btw, I should have said, the banner, colors, and download button look great!

Clearly CSS is the way to go, as much as possible, the trick is to figure out which bits of CSS NN4.x does OK with and which parts it messes up with.  We know the result on NN4.x will look more like a drunken homeless old sheep and not a cute little lamb, don't worry about that.  I think nearly everyone here has personal experience trying to get NN4.x to behave while at the same time using CSS.

We've had the dev website under CVS control from day one. Right now only dave, ola and me can commit to that tree AFAIK. If you need access, just let me know your openacs.org account and I'll take care of it.

1. Before release of Mozilla 1.0 (I've just checked it), there were NO modern browser except Netscape 4.x that would Save Page As... intact, as received from the server. IE ran the page source through an evil parser that completely rewrited everything, and even NN 6 replaced line break characters when saving.

2. Netscape has a more professional-geared interface (many things) for Web designers like me. You can conveniently study how other's pages are made, break out of frames, etc.

3. On a shared computer, you can't "just upgrade the browser". You get to use whatever happens to be installed there. This is very common at my university and whenever I travel.

4. If you do your design for Netscape 4.7, chances are it will work fine in any other browser, requiring at most minor tweaking. Opposite is not true.

5. You get accustomed to a particular interface and don't want to learn quirks of another one.

6. There is a feature in my IE installation that I could not uninstall. It goes through Chinese, Korean, etc. keyboard locales when I switch them, annoying the hell out of me. In Netscape, it's just EN - RU - EN... fine.

Yes, it takes time to get used to buggy rendering engine of NN 4.x (no kudos to Netscape here), but in fact almost every design CAN be done correctly in it.

I was glad to see that OpenACS folks did not adapt an arrogant "upgrade your browser" attitude, but were going to make the site fully compatible.

If I were considering a toolkit (of any serious software, for that matter) and its head site didn't look properly in my Netscape, it would be my last visit to it, automatically.

Developers and testers can download Netscape 4.7x from Netscape software archive and install it.

As we've went along, I've been trying to present, openly and clearly, the facts and the options to everyone. That way I've tried to stop words and works from being wasted. All of us know that unorganized work is likely to be wasted in a project such as this.

That said, in our overloaded situation with migration and apd work, we've been very poor at responding to individual input from you guys. We've always taken your suggestions into consideration, though. In most cases we've just implemented your input, end of story. In some cases we've decided not to implement, and failed to inform you of our motives for doing so. That's bad.

Torben, your design does not look correct (it does not correspond to the design blueprint that won the vote). Those who tell you that it's consistent in different browsers are wrong. There is no reason to believe that we cannot modify the existing code to look more browser consistent than your alternative code does. You can help us with that.

Carl, the sandbox site you point us to is not consistent in different browsers and the design elements are not as flexible as ours need to be (their boxes and side gifs have been expanded to a fixed pixel height). Your latest header suggestion hasn't been implemented (yet) because it didn't really solve anything (it's still too low for NN4.x Linux). Plus its asymmetry between the blue and gray rows and its extremely thin white separating line is a step away from the blueprint.

When we've delivered our final code we'll disclaim responsibility for its further development. Anyone who gets trusted to do so will then be able to revise the work to any extent. But as long as the design implementation project is under our supervision and we're not getting paid to do otherwise we will follow our judgment and that of the community as a whole.

The judgment is:

Go ahead with CSS until we've made the site look perfect in the majority of the browsers and acceptable in the rest. Thus we're not going to make the site look equally disperfect in all browsers (which is the underlying logic of the "base your code on NN4.x" method).

Removing the width=100% attributes in the table and td tags, and replacing them with fixed pixel values works as intended.  So for large tables, at this point, a table of 518 wide (9 + 500 + 9, or 1 + 8 + 500 + 8 + 1) works with the code, but this means issuing code with fixed widths (possibly calculated via the adp template?)...  I know this is not what is needed.

I'll continue working on flexible td width options later today..

Also, I'm entirely sure how they'd determine whether the gif was created with a licensed product anyway???

Lastly, is there no way in the search results to show the date the message was posted?