Forum OpenACS Q&A: New OpenACS website - Please test!
efforts of Dave Bauer, Ola Hanson, myself and many others who have
contributed time, suggestions, graphic design, testing, etc.
Now we need you to go there and pound on the site. Look for flaws,
things we forgot, things that could be improved, etc. If you do find
things that can be improved, suggestions and bug reports will be
highly appreciated, _especially_ if followed by patches (we are in a
Go to http://dev.openacs.org/ and test away.
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.
I've not had a chance to test yet with a release Mozilla package, but I'll try and do so at the first chance I get.
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!
The site looks good and works perfectly on Mozilla 1.x and IE. Good work!
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).
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. =)
I do think it's possible to have it look good in Navigator, too, at least that's my aim. The header and boxes look a little better now on NN 4.77 Linux, but I'm not quite there yet...
If you want to help fix HTML flaws, perhaps you can just wiew the source and post patches here or send them to me?
NN doesn't honor our current css stylesheet in every detail, so I put <font size="-7"> tags around the search field in the header (it is that element and the button that expands the grey cell). Does anybody know how I can make it take less vertical space? It didn't do any good to go below -7...
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...
Feel free to post news and comments, etc, but make REAL postings, not test postings, please. This is actually the database that will be used when we shut this "old" site down.
I think we want to prevent people from posting to the new forum before launch for some technical reason I'm not 100% aware of, or it is a forums bug still lingering... Dave knows more about it, and will surely post about it...
I don't get the "one pixel flaw" on Mozilla 1.00 that you reported (I am on linux). Is it possible you changed the font settings?
Please point us to documents/projects/features, etc, that are related to OpenACS and would be good candidates for the new "Featured Articles" section.
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.
Torben if Ola gives us the green light (to prevent duplicate efforts), you could work on a stable html version of the content... I could work on the header. Ola?
Are the mapping tables migr_message_map and friends in place and filled with the right values?
Torben: Thanks for helping! I hope you find a solution.
I experienced that problem, too, and as far as I can tell text boxes plain suck because they won't adjust their width...
Leaving the box out altogether is one possibility, sure, but note that it disappears when you are logged in, which most users should be anyway
Setting the width of the text fields to 16, sounds like a good compromise... I don't think we need to support a perfectly good-looking layout for screens running a resolution less than 800 x 600.
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,
"Please point us to documents/projects/features, etc, that are related to OpenACS"
dotLRN needs to appear somewhere obvious on the new site (I will see if I can coordinate a short and descriptive blurb).
The Greenpeace site is also something that should jump out at you (they promised to create a whitepaper...)
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 tried on an old post and it worked. The more recent posts (and users) aren't migtated yet.
Could this be it?
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 think the stuff what we can do are:
1. Increase the height of the header a bit. I used the small header version. But as pointed by Carl we must increase it a bit. I will recut the header. Although I am away from my equipment right now I will try to make it as soon as possible. It may not reach launch.
2. Either we move the login box to the right. Or like what some people are discussing in the IRC just remove it. The login box will never shrink or wrap because the text inputs will not do that.
3. I will revisit my corner cuts... I have also seen some problems there.
4. I will see if I can have our QA do some help at least for the home page. We have linux, mac and windows for testing. No promises but I will try.
Since you are creating borders around items it might be nice to provide a generic wrapper that can easily be reused. I am working on a site that has lots of forms. I created a few simple registered tags that I could throw in above and below. If in the future I wish to change the colors or other properties, I just have to create a few gifs and a tag property.
The registered tags look like:
<formtop color="grey" bgcolor="#EEEEEE"> form stuff here <formbottom color="grey" bgcolor="#EEEEEE" button="button-delete" button_color="red">
This generates a form that looks like http://stellardata.com/ms/form.html
This also allows you to have minimum gif image size. In addition, I have a formnobutton tag that doesn't put a button in. You can use this one when you want a regular form submit button, or when you just want to wrap some non-form content.
Of course some complex forms may still be hard to generate using the form builder/ad_form. We may want to add more widgets and form meta-commands (like "section" "info" etc) to the form templater.
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.
version to Ola to be integrated.
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:
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.
Thanks for doing that.
If your company is already listed, but you want to change the listing, please reenter it, and we'll take off the old one. Just email mailto:email@example.com
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.
<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:
I am curios to hear if there are benefits of creating custom templating tags compared to this method
"At the top of box-master.adp:"
should have read:
"At the top of /widgets/postings.adp:"
Your feedback has resulted in a general spiffying up of the design and in small changes of the layout. The login box has been removed and the login links in the header have been altered, making the layout more logical. Otherwise the homepage follows the blueprint.
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.
I believe the site is "functional" in Netscape 4. That is a reasonable level of support. It is too much work to make everything work in that browser. I think the new site does not crash the browser, and all the content appears in a legible manner.
We can never acheive 100% exact look of a design in every browser, so accept that some things in Netscape 4 will look a little different.
Given that everyone made such a fuss about things working in LYNX, I find it hard to beleive we can ignore one of the more major
We also have a lot of problems with 4.x N browsers, however as it turns out its actually that Netscape are much more
strict/fussy about HTML.. Consequently its often this browser that is most difficult to develop for.
Our solution in the past has been to get it right with 4.x and then work up from there.
Also, I personally use 4.x quite a bit, as one of my laptops can't upgrade.
Doubtless there are more people as well..
Also.. Given that the openacs.org site is a relfection of the community, its going to look a bit naff if we can't get it right
for well known browsers.
I do appreciate it a real pain, but in the long run probably worth it.
i think the "width: xx%" CSs could be the issue there. See the second link i posted for info on this bug.
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.
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. </i></blockquote>
This is similar to how one writes a portlet using OF's new portals package (with the new portals package handling the master/slave issues, the "box-master" template would be a theme in the portal package)
<p>This is good because it means we could easily make these pages portals in the future without having to do too much rewriting of your code for these boxes. That would be cool.
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.
We are left with two alternatives - neither of which meaning the actual slaughter of Netscape 4.x, and neither meaning that it will look as cute as a lamb, either:
1. Keep our code as it is, and simply restore the CSS file to the version where the site looked perfect on all browsers except Netscape 4.x, where it was fully legible but had minor beauty flaws. We could even compromise and put the main content on the homepage in a table, slowing up the rendering but shaping the content up in Netscape 4.x.
2. Redo the whole darn...
Actually there's only one alternative.
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!
I'm a bit irritated because we're not getting CVS control over the CSS file. Everybody's just trying to be helpful, and still.. To many cooks and all that.
Sorry for sounding like an asshole.
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.
Try it. The one I posted above works fine, too, but this version works for everything that I have access to.. Mac, Linux, Windows... NN6, NN4, IE5.5, IE5 it even works for lynx!
OpenACS.org now can have a consistent look... Please someone use it... I don't have time to contribute more, but I'd hate to see these hours unnecessarily wasted
See bottom of page for needed changes (browser tests are above).
One last thing: Rich Graves gave this address http://sandbox.brandeis.edu/ as an example that we can pull from. The rounded boxes on his site seem to work better than on the dev site (in other words: download the border gifs, adjust the colors and html source to our design... done).
There are many reasons why people use old browsers. To name a few, let me mention my top 6:
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.
Main Site (p1 of 5) Home Home [spacer.gif] Home o News & Events o Forums & Community o Projects o Documentation [spacer.gif] [spacer.gif] 5092 registered users 2426 downloads of OpenACS log in o register ____________________ Search [head_upright.gif] [spacer.gif] [head_lowright.gif] [upleft.gif] [spacer.gif] [upright.gif] [spacer.gif] News [spacer.gif] [spacer.gif] [spacer.gif] [spacer.gif] [spacer.gif] Aug 03, 2002 OpenACS in Linux World: San Francisco, CA on August 13-15 [spacer.gif] [lowleft2.gif] [spacer.gif] [lowright2.gif] [spacer.gif] [upleft.gif] [spacer.gif] [upright.gif] [spacer.gif] Recent Posts [spacer.gif]
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).
Unfortunately, the new solution doesn't work well with the community page, which has boxes of different sizes - all of which are bigger than those of the index page. On the community page the box sides become quite thick, and irregularly so. This is not the best result we can hope to achieve. We've had thinner and more consistent box side lines in the past.
I'm not trying to belittle Torben's work. On the contrary, I'm trying to make everyone aware of what a complex and delicate work this is. This example simply shows how problematic it is to develop code without having the overlook of the full consequenses of any changes. One might get the idea that one has reached the final solution, when in fact one has merely replaced one set of problems with another. Improving the visual quality of the site across different browsers has to be an evolutionary development, not a revolutionary one.
Another thing, adding alt="" in every <img> makes the site look better in Lynx. We got that idea from Torben's code.
Your kind post about the missing initial table row has left me in confusion. Am I missing something? The decisive 1 pixel high row is indeed there in our code, I can see it with my own eyes. I'm really spooked here.
After spending way too much time comparing your code with ours and testing them both, I have reached the conclusion that the "magic row" is doing its thing in our developing site code, too. And that's why the index page looks so fine. Unfortunately, the row simply doesn't do the trick on the community page, I figure.
I don't expect that you have actually seen how your code handles the community page. I have; it too doesn't work. And that's what could be expected, for the simple reason that we have already implemented your magic into the code of the developing site. It is far from impossible that I have screwed up while testing, but...
Hopefully you know something that we don't so that you can set us straight. Otherwise we'll just leave it for now, and maybe you can start revising things after we've let go of the project - which will be real soon. We at Polyxena are beginning to feel that we've done what we were supposed to do.
So, we'll just give everybody the chance to point out the areas where we have yet failed to meet their expectations - and to send over any neat and safe design patches that can be easily fitted in with the code without too much trouble - and we'll call it a day.
Also, we've made sure that Dave Bauer has added you to the list of site developers, Torben. You really deserve the credit.
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..
I really like the work you all have done on the new site design.
But here's some nitpick:
Is this anti .gif thing something for OpenACS.org to consider?
Also, I'm entirely sure how they'd determine whether the gif was created with a licensed product anyway???
Personally, I like the idea of using PNGs, but am not certain of how well implemented PNG interpretation is in current browsers.
I think the GIF issue parallels the differences between opensource (tolerant to mixed use of intellectually protected technologies and Free Software movement) versus GNU (pure nonprotected/nonliscensed technologies only). OpenACS.org has chosen the mixed use path since it optionally uses Oracle and Microsoft Windows etc. Therefore, the issue seems mute here as a matter of practice.
Lastly, is there no way in the search results to show the date the message was posted?