Website

[Zuu]

It seams like people have neads for talking about the website, so here we go with a thred about our website.

Let me sum up what have been said so far.

From our wiki:
For those who are not familar with our wiki, there exist a discussion page with some suggestions for the website.

Suggestions from the meeting 2004-11-28

Webpage features

• Links to the meeting's logs and minutes.
• Link to the wiki
• Link to tt-forums
• Link to prototypes?
• Info about the project
• A progress bar (example: 89% of the FRD is done)
• Disscussions for visitors
• Link to SF download page
• Link to SF screenshots page

What should go into the wiki?

Zuu: " I think we should have liks to devlopment stuff like prototypes inside the wiki."

...

chriho: "I would say that anything which needs to be decided in close circles needs to go on the wiki rather than the forums."

...

Hyronymus: "Selling a game works with showing eyecandy"

PJayTycy: "That's the reason why I said to put the prototypes on the page"

Recently in the tread Tasks to do in parallel with the DD there have been some suggestions:

Something the website needs to hold:
All the minutes and logs of meetings

Something the website needs to hold:
All the minutes and logs of meetings

For that we could use sourceforges doc manager.

Just decide a name conversion for the files, and upload them. But probably the webpage should have a lik to the doc manager.

However, if you like to discuss the homepage futher, create a theread, so we don't polute this thread.

have some plans for a website. However it will take some time, before I have something to look at.

I will try to observe all suggestions about the website, so post your ideas here (or in a new thread?).

From my mind:
There have been suggestions that we can use the wiki as our website. (se
freeciv for an exampel)

Man, I am tired, so I let you remember the rest, that I have missed

[Steve]

I'm not a fan of using the wiki for a website. It would probaly make it easier for people to add content, but i could never find how to alter many aspects of MediaWiki (the wiki we currently use), so it would lack a proper website structure without A LOT of work.

In the future, we'd need a proper website anyway, which a wiki doesn't provide. I think it makes sense to start with a proper website whilst we have limited things to do, rather than end up throwing together some rubbish at the last moment.

[Zuu]

For the technical, I would suggest that we try to integrate with sourceforge. Ie instead of create a separate news system, we can use the RSS freads with the news from the news system on sourceforge.

There exist some other RSS feads for our sourceforge project, including file releases.

As everything integrating with sourceforge have both good and bad sides.

Good:
* Easier to maintain one source than two.
* News that are posted via sourceforges news system, have a chance to show up on sourceforges front page (after human sorting).
* On Sorceforge, diffrent developer acounts can have different permissions. (allow post news, docs, files, etc.)

Bad:
* If a RSS fead goes down, we wont have anything to show on our homepage.

[ChrisCF]

I'm not a fan of using the wiki for a website. It would probaly make it easier for people to add content, but i could never find how to alter many aspects of MediaWiki (the wiki we currently use), so it would lack a proper website structure without A LOT of work.

Out of interest, what aspects are you referring to, and what constitutes a "proper website structure"?

[Steve]

Where you have a navigation bar a main section, space for ads, etc. Even if you do heavily modify the wiki to provide that, Wikis are slower (typically) than a set website anyway.

[Zuu]

5. Other tasks

[...]

- Zuu will lead the Website team.

Later this week (I hope), I will write a longer text with some kind of plan, for the work. However this week I am rather short in time, as I have a big physics test on friday.

I've voluntered for this role, becuse noone else voluntered at the meating, and I think it is currently probably the most important task, of the tasks that I was interested in. I am not as experinced as ChrisCF when it comes to project leading (and probably other tasks to), but I will give it a try, to push this task forward. If there are anything you think that I am doing in the wrong way (or that can be done on a better way), please tell me, via PM or Email. (Ask for my address via PM.)

It is possible to change team leader, later on, for one or another reson.



Now, I must continue with my physics .

[Hyronymus]

Just keep us informed on your progress and don't hesitate to ask for a helping hand. But good luck with physics first.

[Zuu]

don't hesitate to ask for a helping hand.

That was the plan (to get some others to join). Becuse not only that it would be much work to do by yourself, I am not the ultimate when it comes to designing good looking wesites. (Just take a look on this and this, and you'll know what I mean.)

But before I ask people to consider to join, I want to pressent my plan that are folting around in my head. But, if someone feals that they want to take an active part in the website team now, thats fine. Just post.

[Purno]

But before I ask people to consider to join, I want to pressent my plan that are folting around in my head. But, if someone feals that they want to take an active part in the website team now, thats fine. Just post.

post.

That means I'm interesting in doing some design and such

[Zuu]

Thats noted. Please watch this thread, for updates.

Edit: okay that didn't sount that enthusiastic.

[Steve]

Tables are not for layout. They are for displaying tabular data.

[ChrisCF]

Tables are not for layout. They are for displaying tabular data.

Pardon my pedantism, but isn't the organised display of tabular data technically layout? In particular, in the absence of anything which does better while still looking vaguely similar no matter how you look at it, what alternative do you suggest?

[Prof. Frink]

You asked for this.

Pardon my pedantism,

It's "pedantry".

[ChrisCF]

You asked for this.

Pardon my pedantism,

It's "pedantry".

Congratulations on spotting the deliberate mistake. Pedants of the world unite!

[Zuu]

Tables are not for layout. They are for displaying tabular data.

Pardon my pedantism, but isn't the organised display of tabular data technically layout? In particular, in the absence of anything which does better while still looking vaguely similar no matter how you look at it, what alternative do you suggest?

Neither OpenTTD nor Wesnoth use any tables, on their pages (at least thier index pages). TT-forums, on the other hand use lots of tables.

By using <DIV> elements and CSS code, you can do qute A LOT designs. If you have Firefox, and webdeveloper extension, you can turn of the usage of CSS markup. You can also outline tables. This way you can easy find out how a tablebased website is structurated.


One big adventage with the <DIV>/CSS model, is that if you use the <H1>,<H2>,.. tags correctly the website will be easy to use on text based browsers, and eaven spech based browsers. Still, you can via CSS add lot of eye candy if you like, for users with browsers capable to show advanced graphics.

[PJayTycy]

http://www.csszengarden.com/


The html doesn't contain any tables, only a structured use of <div>'s and <h1>, <h2>, ...

Artists can submit their own css file to change the appearance of the site. Just choose one of the other theme's to see a probably completely different layout (the theme-links might suddenly change from a left-side bar to a right side-bar or maybe even a bottom-bar).

[Zuu]

Well, here is some of my thoghts just written down in vim. They're not final or anything like that. So please comment.

I havn't botherd to format it, as it will be stored in the wiki, when ChrisCF is done with the preperation of the wiki (creating templates for task pages).

Code: Select all

Basically the plan is:

        1. Researching parse
        2. Implementing parse
        3. Testing parse
        4. Documenting parse

I am not 100% sure if testing should be before documenting. Obviously it will be good if we documents during the other phrases. But still I think it is good if we take us time to make some documentation of what we have created, when we are "done". This does also apply for the test parse.

Hopefully We wont see the website team shrink when we come to the documenting parse. :D Also nothing should hinder us from go back to earlier parses.


Researching parse:
        * Who are the target users? New/old users/developers
        * Which functions/pages should it provide (including administrative functions)
        * What techniques exist? html,xml,css,php,javascript.. pros/cons
        * What are we (the team members) good at?
        * Level of compatibility (with browsers/standards)
        * Any other requirements?
        * What does the law says? (do we have to inform about cookies etc.?)
        * How shall the site be hosted?

        * What do we want to say with our design?
        * Different layouts pros/cons
        * Different colour/image designs pros/cons

        * How shall we mange content/design technically?
        * How shall we backup the site?

Implementing parse
        * make layout of html/xml/css (or what have been decided)
        * add php code
        * add text/content

Testing parse
        * Validate all pages against decided standards/browsers.
        * Check for security holes.

Documenting parse
        * Which files do what.
        * Instructions for administration
        * Known limitations
        * Whatever

[Grunt]

I'd think that documentation should be mostly done throughout the implementation and testing phases - it can be quite annoying to have to look through code that you wrote "ages" ago and attempt to figure out what it does again. It's much easier to document your thought processes whilst you're still creating and testing.

[PJayTycy]

About the implementation phase:

Before creating a layout, we should define the overal site's structure (sitemap / table of contents / menu structure / ...).

[Zuu]

I'd think that documentation should be mostly done throughout the implementation and testing phases - it can be quite annoying to have to look through code that you wrote "ages" ago and attempt to figure out what it does again. It's much easier to document your thought processes whilst you're still creating and testing.

Yea, thats true, however it might be good to have a resambling step, where you look over the docs.

About the implementation phase:

Before creating a layout, we should define the overal site's structure (sitemap / table of contents / menu structure / ...).

My plan was that that would be a part of the research step, maybe I wasn't clear enoght about that.

But it might be clever to have parts of that work, Ie the final decissions of where every pece should go in implemention parse.



Another question, how serious should we go with the homepage? Both layout and design, but alson in content. How much content shall we have on our website.


What to do now?
I think we shall begin with the research parse. (Surprise! ) But how shall we do that?

If you look at the list of questions under research, you'll see that there are points that is more or less just discussion points, while other points requires that somebody does some reserach, before a discussion can take place. In bothe cases a decission has to be made after the discussion.

If there aren't any better suggestions I'll create one topic for each reserach point that can be discussed straight ahaed, without any research. I will create them in this forum, becuse I see no reson to dissallow non-developers to post.

Website team
If you intend to take an active role in the website team, ie not just "make a design" but also the less fun parts too, I think you should officially join the website team, and not just throw in a comment here and there in the research threads.

I won't have verry mush time untill mid June, as I'm om my last year of school. I will (very likely) have some time for TEmpire. What I want to say is that if noone helps out with the website, there will be some progress, but not as mush as if you joined.