Closed Bug 260137 (svgsite) Opened 21 years ago Closed 19 years ago

Update/redesign the SVG project's website

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jwatt, Assigned: jwatt)

References

(
URL
)

Details

I'm working on updating the SVG project's website and hope to redesign some parts of it. I'm filing this bug in the hope of getting the maximum input possible from all interested parties. It isn't easy to have new files removed from the CVS server, and any directories that are added are permenant, so I'd like to get this right. While the work is ongoing I'll be maintaining a mirror of the site which will incorporate all the proposed changes at http://jwatt.org/moz/svgsite/ to allow everyone to see what it will look like. If anyone has any comments, suggestions or requests this is the place to make them. Things that I'd like to propose or that I know need doing are as follows. We need a webpage explaining how to get involved and what we need help on. Perhaps we should make a file called 'contributing.html' for that? I would like to move each of the sections on the front page into their own documents. At the moment we have a section called "status" plus the status webpage. I would like to keep these things together by, for example, moving the status section to the top of the status webpage. This wouldn't leave the front page empty because: I would like us to have a news section so that people can see what has been happening recently. There is a lot of stuff that could go onto a news page that doesn't have an impact on the status page. There could be a separate page for this, but I would like to put the news on the main page. I.e. a dated list of items right down the middle. We should probably have a collection of SVG samples that show off what our current SVG implementation is capable of doing. At the moment there are samples on croczilla.com. This is one thing we probably want to add a new directory for. We could do with a contributors list - perhaps a page in its own right? I don't know how much detail should be given about what each person has contributed, or if we should just have a list of names. There are other things that I have probably forgotten, but I'm sure I'll remember and add them later. If anyone has any opinions the above or on the SVG projects website in general please speak up. Thanks! :-)
jwatt: great bug, congratulations! first more or less the same comments I posted to Aaron: The homepage really has to use SVG, people wanting to download get sent to some other page. check peepo.co.uk The navigation bar on the left is wholly inappropriate, and example of the worst sort of bureaucratic corporate style control. Once people have chosen to visit MozillaSVG, they need relevant navigation, not the standard Mozilla navigation bar. (download source is not MozillaSVG and this is confusing, at least) perhaps the tabs at the top could remain. dump <table> these aren't tables, and should not be there let <div> do the work. Each resource or page needs a mozillaSVG icon, and/or text header, to make clear that this is a mozillaSVG area,with a link to the mSVG homepage. links to other versions: firefoxSVG, fireflySVG... A link to bugs A link to irc a link to a blog a link to accessibility mozilla and Aaron desperately need more accessibility contributors. this seems to me the main strength of open source and Mozilla in particular. the new Mozilla web design is great, but isn't as acceptable as a beacon of accessibility links to examples of excellence: peepo.co.uk, crockzilla links to tutorials, kevlindev links to commercial users: mobile phones, ok maybe wait for fireflySVG ~:" I could almost offer to manage this area, but being bloody minded and difficult....probably not the right person. I guess that is enough for now ~:"
Blocks: validate
Great, thanks for your input Jonathan. First off I'm not sure what you mean about using SVG on the homepage so people aren't sent somewhere else to download. By this I pressume you're talking about when people are told they need to install a plug-in? This happens when an embed or object tag that requires support for the MIME type image/svg+xml is encountered by people using a non-SVG build. Redirecting them to the plug-ins page isn't going to change, and I really don't understand how making changes to the SVG project homepage would change Mozilla's behaviour. Yeah, I can see how the navigation bar on the left would be confusing for users that have linked into the project website directly and are unfamiliar with the rest of mozilla.org. It could be removed and replaced by a navigation bar of our own. I'd have to be careful with that though as making that change can potentially muck up the build process for the whole of mozilla.org! :-) The tabs at the top could remain, and could even be changed to a more detaild menu. I agree that we are technically abusing tables at the moment. I'll look into what else we could use while still supporting all the main browsers. We could add a logo or something to the top of each page, but I'd personally like to have something a bit slicker than the one we currently have. Anyone here any good at knocking up some graphics? Yeah, yeah. I see the irony. There will be links to downloads for all SVG products available on mozilla.org. I assume that's what you meant. There are links bugs, is there anything in particular you want mentioned? IRC is mentioned, but we can add a link and say some more about it. We may well have an SVG blog to link to. Although I personally think accessibility is important work, we would need a better reason to link to it than that it needs more contributors. It would be good to have links to lots of useful sites. If you have any more sites you think should be liked to add them here. We have 3 people with access to gila so I don't think we need a maintainer, but thanks for the offer. :-)
Alias: svgsite
Summary: Update/redesign of the SVG project's website → Update/redesign the SVG project's website
My comments are often veiled, so second stab: the links I mention could be in a navigation bar, as well as dotted throughn the news content homepage. the homepage could be totally in SVG, peepo.co.uk/launch/index.svg is. my point is that SVG unlike flash has the potential to be a web interface. (flash is a destination, svg a means to get there) Mozilla could set an example both for accessibility and SVG as a portal. obviously this would impact on the authoring, however, as gnome desktop is already moving towards SVG graphic navigation buttons are likely to benefit from SVG as a minimum. so the whole mozilla site would benefit in the future :-) there aren't too many SVG portals just now, and we could do with one here! It would certainly help guide accessibility of SVG which whilst promising much with SVG1.2 is hard to come by just now.
The page definitely should not be in SVG, as we want to get people involved in the project. Ending up at a page which just pops up an unknown mimetype message, and for which many platforms doen't have a viewer for, does not do that.
#4 mistakes the novice introduction homepage which should be in HTML with the user homepage. Novice introduction homepage, probably has all mozilla normal navigation. It certainly should not have masses of geeky mysterious links User homepage should be in SVG, we need the good example code.
#4 I agree the novice introduction homepage which should be in HTML, and probably has all mozilla normal navigation. it should not have masses of geeky mysterious links but be simple with introductory links I was referring to the user homepage, which should be in SVG, we need the good example code. In fact it is relatively easy to script so that people with a suitable browser get forwarded to the SVG site
Depends on: 247558
No longer depends on: 247558
Okay, I've uploaded a FAQ to http://jwatt.org/moz/svgsite/faq.html to give everyone a chance to give feedback on it before it get's uploaded to the project site. Anne, please confirm this doc meets your HTML 4.01 strict requirements before it gets added to mozilla.org.
Ok, the document doesn't validate at the moment. Some & have to be replaced with &amp; and some character are not valid in iso-8859-1, but those cases are easily resolved. We don't need a BASE element, but I assume it is there for other reasons. We should use '<ol class="toc">' instead of '<ul>' with a matching '</ol>' of course. Instead of H3, the headers that follow should be H2. After all, H2 does follow H1, where H3 does not. &lt;script&gt; should be wrapped inside a CODE element. This applies to similar cases. I'm not sure why you link to 'about:plugins' if it doesn't work. The ADDRESS element should have a CLASS attribute with the value 'author'. The rest looks lovely!
Anne, thanks for your comments. I've addressed most of the issues you raised and added a section "Who's currently working on what?". (In reply to comment #8) > We don't need a BASE element, but I assume it is there for other reasons. That's just the easiest way to get the pages on the mirror to get the correct styling. It won't be included in the document that's checked in. > We should use '<ol class="toc">' instead of '<ul>' with a matching '</ol>' of > course. Instead of H3, the headers that follow should be H2. After all, H2 does > follow H1, where H3 does not. I don't really want an ordered (numbered) list, and h2 looks too large for the questions for my liking. > The rest looks lovely! Thanks. :-)
Status: NEW → ASSIGNED
none of the contents (toc) links work for me :-(
If you don't like the size of the H2 you should contact fantasai or someone else who can modify the central style sheet. (There is a bug where people want headings to be larger.) However, it is a normal rule that H2 follows H1 from a semantic point of view. The look of the site will always change, every couple of years and nothing you can do about it ;-) The same goes for OL. (You can let it be styled exactly the same way as it is at the moment.) jonathan chetwynd, that's correct and intentional at the moment.
Regarding SVG 'internals' documentation for the OSX platform..... We have been working on the OSX version of the SVG viewer for a bit now (since March, to be specific). While progress has been made, things are on hold for a bit while we prepare for a demonstration in Washington in a few weeks. Some early patches of the work have been circulated to Alex et. al, but as the OSX interest has languished a bit, we haven't really made it into the mainline development process (yet). That said, we are now to the point where at least the colors on the croczilla test site do show up correctly. As part of our work, we are drawing up some PDF's that illustrate the relationship among the different drawing surfaces that are in play during the rendering phases (again, this document will be Quartz specific). We are building that document to help out newcomers in understanding what on earth is happening when something gets drawn on the screen. We hope to be back on track with our OSX development in a few weeks, and once this work receives the support of an expert mozilla sponsor, the link to the documentation will be made readily available for access from the new SVG site. Best to all - KCF
(In reply to comment #4) > The page definitely should not be in SVG, as we want to get people involved > in the project. Ending up at a page which just pops up an unknown mimetype > message, and for which many platforms doen't have a viewer for, does not do > that. Is a wise position to me. Also, we are very appreciative at the SVG Foundation for the link to our http://www.svgx.org and hope it will remain. (+lots of Mozilla stuff at http://www.svgx.org/subjectsbrowser.html ) Thank You Michael Bolger
FAQ this seems fairly urgent, if only to stop me being a pain in the neck: eg colour not working on mac and https://bugzilla.mozilla.org/show_bug.cgi?id=62485 need to use javascript rather than ecmascript.... and use/symbol not supported and no sound sounds like a plan for the future perhaps someone could add some positives there are a few ~:" irc svg-developers
> there aren't too many SVG portals just now, and we could do with one here! please add www.svgopen.org to the links
1: The links at the top of the FAQ aren't pointing to the right place. 2: I think http://jwatt.org/moz/svgsite/faq.html#source can be improved: Cause a lot of people trying out SVG don't know or are not allowed to change server settings, the mime type thing can be a problem unable to solve for them. But with a little help from somebody who can do that on some server: <?php header("Content-type: image/svg+xml"); echo(file_get_contents($url)); ?> Please make this service widely available.
QA Contact: daniel.bugmail → fantasai.bugs
I've added http://www.mozilla.org/projects/svg/faq.html to the website (although I haven't linked to it from any of the other webpages yet). (In reply to comment #16) > I think http://jwatt.org/moz/svgsite/faq.html#source can be improved: > Cause a lot of people trying out SVG don't know or are not allowed to change > server settings, the mime type thing can be a problem unable to solve for them. If you're asking for the answer to explain how the user should fix this, I don't think the FAQ is the place to do it. There are far too many possible ways to fix the HTTP header problem for it to be practical to mention them all there.
What's the status on this bug?
I've stalled on it for the moment. If anyone is keen for me to move on this one, feel free to bug me on IRC. What do you still need done to the SVG Project site to remove this as a blocker of bug 151557 Anne?
This page <http://www.mozilla.org/projects/svg/> and possibly deeper nested pages (inside the folder /svg/) need to validate as HTML 4.01 Strict and need to match the style and markup guide of mozilla.org which can be found here: * <http://www.mozilla.org/contribute/writing/guidelines> * <http://www.mozilla.org/contribute/writing/markup>
The page mentions SVG is enabled in nightly builds; it should also say it is in the released version Firefox 1.5! There needs to be a section addressing people who already have SVG content and who want to get it working in Firefox. This means things like workarounds for bug 288276, the lack of SMIL animation (e.g., http://www.vectoreal.com/smilscript/), and some of the weirdness caused by Mozilla treating SVG images as a variation on HTML documents (spurious scrollbars in embedded images, surprises with linking, etc.). Hints on eradicating bad advice people may read elsewhere (e.g., some servers still use the MIME media-type image/svg-xml; some SVG examples have the wrong XML namespace or none). You could also do with an organized page of really cool demos using SVG. Actually, you could do with *two* sets of demos: one set showcasing things possible with mixed XHTML + SVG + MathML, and one showing how embedded SVG can work in Firefox and with Adobe's and Corel's plug-ins. Just my 2c worth... :-)
I've done as much as I'm going to do on this for the foreseeable future so I'm marking this fixed now. If anyone feels strongly about any outstanding issues then please raise new bugs.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
I think it is a pity this bug has been closed. work has been slow, but it appears to have been a useful repository for exchange and consideration. separate bugs will lack that cohesion.
Product: mozilla.org → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.