Website re-design contest on deviantART!
Hey all!
The inkscape deviantART community is holding a contest for a makeover to the Inkscape website (http://www.inkscape.org). All of the details (which I will post below as well) can can be found at: http://inkscapers.deviantart.com/journal/6322909/
---begin dA announcement--- Hey there fellow Inkscapers!
Many of us have seen Inkscape evolve from back in the days of Sodi Podi into the powerful program that we currently know it as. Unfortunately the website has not quite followed along at the same pace. ;) Which brings us to the next official inkscapers contest, a makeover for the website!
Basics: *The goal is to show off what inkscape can do when put to use in the area of Web Design. *You will need to make a new Header, Footer, and CSS to replace the existing ones. *Upload a preview image & 7z/zip/tar file of your submission to your gallery or scraps on deviantART and post a link below.
Rules: *All submissions must be standards compliant (XHTML 1.0 Transitional & CSS) and render the same across all browsers (within reason of course). *Any images that you create for it need to be done 100% in Inkscape. We will require any original SVG files to use in case something needs to be tweaked down the road, and also to allow us to potentially serve up SVGs for the browsers that support it. *It must be a very clean and professional design. *It must include the Inkscape logo in the site header. *Any submissions using copyrighted materials (unless appropriately licensed for our use) or offensive/inappropriate content will automatically be disqualified. *Have fun!
Deadline: *September 15, 2005
Prize: *Having your design be our new look and feel for the website... and of course credit for your work.
Judging: *Preliminary judging will be done by the Inkscape community on deviantART, when we have an official “Top 3”, the judging will then be turned over to the inkscape developers for final judging. Please note that when it is turned over to the developers for voting, once they have chosen the winner, they may have requests for modifications.
Relevant links: *Inkscape Website – http://www.inkscape.org/ (where you can go and grab the current source) *Inkscape downloads page – http://sourceforge.net/project/showfiles.php?group_id=93438
Submissions: *Please upload a preview image & 7z/zip/tar package of your submission to your gallery or scraps on deviantART and post a link below.
Good luck to all who enter! ---end dA announcement---
-Josh (aka ScislaC on dA)
PS: For those unaware of what deviantART (dA) is, dA is the largest community art site on the net. To find out more go to http://www.deviantart.com/
This sounds great, but I have a few comments.
First off: Is there going to be -- or should there be -- guidelines about the layout. ie, do we want to stick with a single left column with a header and footer? Or are people allowed to use their creative judgement with this?
On Thu, 2005-08-25 at 08:49 -0700, Joshua A. Andler wrote:
*All submissions must be standards compliant (XHTML 1.0 Transitional & CSS) and render the same across all browsers (within reason of course).
Why Transitional? I think this is a really bad idea; Transitional DTDs are designed for when you are *transitioning* from a previous standard. If the website is being completely redesigned there is *no* reason not to use a strict DTD, other than laziness.
Also, it might be wise to mention the separation of content from presentation. It's perfectly possible to pull of an XHTML/CSS site using horrible non-semantic markup and using CSS just to change the fonts. But that would be stupid.
Another thing is that it might be good to specify accessibility guidelines to aim for. Accessibility will *always* be down to human judgement to an extent, but it might be nice to say "try to follow the WCAG level 2" or something.
Finally, I think you absolutely must define the browsers in which is must perform well in. Surely you don't want to support NN 4? What about really uncommon browsers? It's better to have a list I think. (When I say "support" I really mean "serve CSS to".)
Deadline: *September 15, 2005
I'd say this is slightly too soon myself.
Jonathan Leighton wrote:
This sounds great, but I have a few comments.
First off: Is there going to be -- or should there be -- guidelines about the layout. ie, do we want to stick with a single left column with a header and footer? Or are people allowed to use their creative judgement with this?
I think we should see what people come up with. However, if you would like it as painless as possible, I can modify the language to be "re-skinning" the website, that way it's known that the layout needs to remain the same.
On Thu, 2005-08-25 at 08:49 -0700, Joshua A. Andler wrote:
*All submissions must be standards compliant (XHTML 1.0 Transitional & CSS) and render the same across all browsers (within reason of course).
Why Transitional? I think this is a really bad idea; Transitional DTDs are designed for when you are *transitioning* from a previous standard. If the website is being completely redesigned there is *no* reason not to use a strict DTD, other than laziness.
Why 1.0 Transitional? Because that's what we currently use. A while back I had said I wanted to convert us to Strict 1.1, but that was shot down due to _some_ compatibility reason (I don't recall what it was offhand). I just didn't want to go there again or do anything that would make major changes without approval. If others think it's fine to do 1.0 or 1.1 Strict, by all means I'm all for changing it.
Also, it might be wise to mention the separation of content from presentation. It's perfectly possible to pull of an XHTML/CSS site using horrible non-semantic markup and using CSS just to change the fonts. But that would be stupid.
I think that as far as the XHTML/CSS stuff goes, yes it does need to have a separation of content and presentation... I personally assume it goes with the territory of XHTML & CSS 'best practices' and is fairly common knowledge. However, I'm not everyone else, so I will go ahead and make note that they are required to be separate.
Another thing is that it might be good to specify accessibility guidelines to aim for. Accessibility will *always* be down to human judgement to an extent, but it might be nice to say "try to follow the WCAG level 2" or something.
Accessibility is great, but inkscape isn't really the type of program that is able to cater to those with accessibility needs (namely visual needs, which is what they focus on most with accessibility). So, I can definitely specify that it needs to be accessible, it's just kinda overkill in this case (although basics like alt tags for images are good practice anyway, as are a couple other things accessibility brings to the table). So, does anyone want to chime in on what level of accessibility we should shoot for?
Finally, I think you absolutely must define the browsers in which is must perform well in. Surely you don't want to support NN 4? What about really uncommon browsers? It's better to have a list I think. (When I say "support" I really mean "serve CSS to".)
I do note that it should support all browsers within reason. If we start to specify which ones (except for maybe saying "all modern browsers"), it will start a flood of "what about obscure browser X version Y?" comments. And I think that the standards compliance will take care of Lynx. ;)
If you really feel I need to specify, what ones would you like for me to list? Mozilla 1.x, Firefox 1.x, IE 5.5+, Opera 7+, Safari, Konquerer, Epiphany... do you want lower version numbers? more browsers listed? what about TV based browsers? and mobile device browsers? what else?
Deadline: *September 15, 2005
I'd say this is slightly too soon myself.
We actually already extended it earlier today, I just hadn't reposted to the list. September 25 is the new date so it is one month from today (you can thank Cornelius for that). If you think it should be longer than a month, just let me know.
I will wait until I get a few of the above Qs answered before actually updating that journal entry. Thanks for the input!
-Josh
Accessibility is great, but inkscape isn't really the type of program that is able to cater to those with accessibility needs (namely visual needs, which is what they focus on most with accessibility). So, I can definitely specify that it needs to be accessible, it's just kinda overkill in this case (although basics like alt tags for images are good practice anyway, as are a couple other things accessibility brings to the table). So, does anyone want to chime in on what level of accessibility we should shoot for?
Not that its a requirement for me at all, but how about those with very poor sight. There are plenty that can read with high zoom levels, and even do a lot of graphics work if they can zoom in or stick their faces to the screen. Zooming and other images is a hard one to deal with but still, might be a suggestion.
Craig Scribus Team
Craig Bradney wrote:
Accessibility is great, but inkscape isn't really the type of program that is able to cater to those with accessibility needs (namely visual needs, which is what they focus on most with accessibility). So, I can definitely specify that it needs to be accessible, it's just kinda overkill in this case (although basics like alt tags for images are good practice anyway, as are a couple other things accessibility brings to the table). So, does anyone want to chime in on what level of accessibility we should shoot for?
Not that its a requirement for me at all, but how about those with very poor sight. There are plenty that can read with high zoom levels, and even do a lot of graphics work if they can zoom in or stick their faces to the screen. Zooming and other images is a hard one to deal with but still, might be a suggestion.
Craig Scribus Team
Swish! Okay, you nailed that one. Very good point.
-Josh
On Thursday 25 August 2005 21:54, Craig Bradney wrote:
Not that its a requirement for me at all, but how about those with very poor sight. There are plenty that can read with high zoom levels, and even do a lot of graphics work if they can zoom in or stick their faces to the screen. Zooming and other images is a hard one to deal with but still, might be a suggestion.
Agreed. Accessibility isn't about giving access to people who might be in your target market. It's about not excluding people from society unnecessarily. Just as we shouldn't disregard someone's right to watch a football match or to discuss a football match because they can't personally play with their disability, so we shouldn't disregard any potential interest in the Inkscape product or community, even if the current product might be unusable to them.
For all we know, a disabled user could have a dream to revolutionise art applications' user interfaces in a way that makes ability or disability irrelevant. At the very least, they're entitled to know what they're missing, and that means letting them read the content about the product, even if they can't USE the product as-is.
Also, accessible sites tend to be much more usable for non-standard browsers like PDA micro-browsers, text-based browsers, etc. No point discouraging potential users who happen to be in text-based IRC at the time they hear about inkscape, if there's no need to do so.
I think we should aim for WCAG-AA *at least*.
On Thu, 2005-08-25 at 13:47 -0700, Joshua A. Andler wrote:
*All submissions must be standards compliant (XHTML 1.0 Transitional & CSS) and render the same across all browsers (within reason of course).
Why Transitional? I think this is a really bad idea; Transitional DTDs are designed for when you are *transitioning* from a previous standard. If the website is being completely redesigned there is *no* reason not to use a strict DTD, other than laziness.
Why 1.0 Transitional? Because that's what we currently use. A while back I had said I wanted to convert us to Strict 1.1, but that was shot down due to _some_ compatibility reason (I don't recall what it was offhand). I just didn't want to go there again or do anything that would make major changes without approval. If others think it's fine to do 1.0 or 1.1 Strict, by all means I'm all for changing it.
Not, 1.1, 1.0. But yes, I think we should change it. I am an "all or nothing" type person, and would probably even favour using content negotiation to serve application/xhtml+xml, but let's not go there...
The current home page doesn't validate at the moment anyway, and validating with a script DTD doesn't produce that many more errors -- most of which would probably be fixed if the "template" was written as strict anyway.
Furthermore, the strict DTD is transitional-compatible, but not the other way around. Therefore, enforcing a strict DTD for the template wouldn't even mean we *have* to use a strict DTD in the actual site. You can't really argue with that.
Another thing is that it might be good to specify accessibility guidelines to aim for. Accessibility will *always* be down to human judgement to an extent, but it might be nice to say "try to follow the WCAG level 2" or something.
Accessibility is great, but inkscape isn't really the type of program that is able to cater to those with accessibility needs (namely visual needs, which is what they focus on most with accessibility). So, I can definitely specify that it needs to be accessible, it's just kinda overkill in this case (although basics like alt tags for images are good practice anyway, as are a couple other things accessibility brings to the table). So, does anyone want to chime in on what level of accessibility we should shoot for?
That's really a very narrow view of accessibility. What about visually impaired people (like Craig said), what about people who use devices other than a keyboard and a mouse, what about <bla bla bla insert accessibility rant>. Really, accessibility should be making [the website] as accessible as possible to as many people as possible. Don't get me wrong, I'm not thinking we're doing a great crime in this area at the moment, so perhaps you are right -- but perhaps it would be good just to say "please consider the accessibility of your design" or something similar.
Finally, I think you absolutely must define the browsers in which is must perform well in. Surely you don't want to support NN 4? What about really uncommon browsers? It's better to have a list I think. (When I say "support" I really mean "serve CSS to".)
I do note that it should support all browsers within reason. If we start to specify which ones (except for maybe saying "all modern browsers"), it will start a flood of "what about obscure browser X version Y?" comments. And I think that the standards compliance will take care of Lynx. ;)
If you really feel I need to specify, what ones would you like for me to list? Mozilla 1.x, Firefox 1.x, IE 5.5+, Opera 7+, Safari, Konquerer, Epiphany... do you want lower version numbers? more browsers listed? what about TV based browsers? and mobile device browsers? what else?
I guess you are right. I prefer to have things set in stone, but trying to define an acceptable set of version numbers would probably just fuel a flame war, so maybe it's better to just use judgement as you say.
participants (4)
-
Craig Bradney -
Jonathan Leighton -
Joshua A. Andler -
Lee Braiden