search

tdwg / infrastructure

TDWG infrastructure
5 stars 1 forks source link

Rethink TDWG website #61

Closed peterdesmet closed 4 years ago

peterdesmet commented 8 years ago

We're getting to a state were the components that made the TDWG website so complex, are no longer tangled together as one big knot:

That means we can start to rethink what remains of the TDWG website on 3 levels:

Content

Make the website an inviting place for our community and visitors: what do we do? how can they contact us? where can they see our activities (IG/TG & conferences) and outputs (standards, ...)? how can they contribute?

What we need:

Use a platform that makes it easy for the whole community to (suggest to) update the website, ideally with a lean editorial process and revision history. The platform should also be easy to maintain (admin tasks etc.).

What we need:

Design the website in such a way that it is easy to navigate and pleasing to look at. This can be extended to updating the look and feel of TDWG as a brand. What we need:

These 3 levels are intertwined and all this work is of course related to other changes being proposed, such as a renewed standard maintenance process, new exec structure, redefining IG/TG, etc., but I wouldn't wait until all that is settled, before starting to rethink the website. Creating a more inviting and easier to maintain TDWG website is the main reason I joined the exec, so I'm eager to work on this over the next two years, but I'd like to know: 1) if the @tdwg/exec and larger community approves this idea, giving a focused group of people the mandate and budget to tackle this and 2) who wants to collaborate?

dkoureas commented 8 years ago

I fully agree with analysis @peterdesmet. TDWG site needs to be simplified, expose our key products in a much more impactful and user friendly way and through a new branding. I am happy to help out with this.

WUlate commented 8 years ago

I am in! I want to be part of this process...

You see, the other day I was in a meeting and I overheard someone using TDWG as an example of a place where nothing could be found and things were not done... of course, I didn't like it and I could've argued with this (loud) person his generalized argument with concrete points (which he didn't provide), but instead I tried to do something more fruitful, I tried to understand why he was saying that and how we could improve this perspective. My thoughts were, of course, on the processes we are establishing and the website itself...

I agree on most of the things mentioned: user-friendly (simple, easy, inviting), up-to-date, impactful... but then who wouldn't? Having been in a UI redesign for our project, I know everybody has an opinion when it relates to beauty and they don't necessarily converge. That's why I believe we need to have clear objectives (as mentioned by others above: "expose our key products", "easy to contribute", etc.) and avoid imprecise or subjective goals (like "pretty", or "easy for the WHOLE community"). I would also be careful of additional tasks unless we are able to support them (with the current or new structure) like an editorial process or a new branding (Please, don't let us fall into the "We need a new logo" whirlpool).

For these reasons, I agree on the idea of working for a new website redesign, but I think we should be closely informed by the structural changes and new processes in place to be able to evaluate how relevant features might be.

dkoureas commented 8 years ago

As you all notice these discussions could take for ever. I think we need to have a small group of people assigned to this: There are three main pillars of work:

mdoering commented 8 years ago

Please consider at least some static site generators like Jekyll or Hugo for a new website. My vote is for the simplest solution and least server maintenance - sth we utterly failed in over the past decade

stanblum commented 8 years ago

+1 for considering Jekyll (integrated with GitHub).

But FIRST we have to be absolutely clear about the functions that need to be supported. This is what William was alluding to. So I think functional inventory and analysis comes first.

I think everyone agrees it would be great to get off of Typo3! Learning curve is too steep, and expertise is rare and expensive.

On Wed, Feb 24, 2016 at 9:17 AM, Markus Döring notifications@github.com wrote:

Please consider at least some static site generators like Jekyll or Hugo for a new website. My vote is for the simplest solution and least server maintenance - sth we utterly failed in over the past decade

— Reply to this email directly or view it on GitHub https://github.com/tdwg/infrastructure/issues/61#issuecomment-188359046.

WUlate commented 8 years ago

In Spanish we have a saying: "Más vale malo conocido que bueno por conocer" meaning "I'd rather have known evil than good to be known"

All tools will have a learning curve; to consider it steep or not, might be subjective. And almost all of those tools that survive the stand of time are "easy to use" or "suitable" for SOME of the things you may want and "adaptable" or "expandable" to the other ones you'd like. But it's when you start adding requirements (specifically those that the tool didn't contemplate) when things get "difficult" and decisions can change.

I am not so sure that our requirements have changed so drastically (a few may have, but I don't think all of them)... I do think that some decisions were taken quickly to see prompt results (I don't mean this to be necessarily bad, au contraire, it might have been the right thing to do at the time: step up, do something!). But I also suspect that if we start compiling a list of all what we want for the site, we might end finding out we would choose Typo3 if not even a far "worse more complex" solution.

I think our current extensive embrace of Github on the site seems to be guided by 4 things:

1) The drop (or addition?) of some previous requirements. 2) Github might be "easier" for certain things we want (not all though, in some places we might be "accommodating" to what the tool offers). 3) The set of people currently deciding (talking or doing) know Github already. 4) It's a change (and it's hip)! (can't say for better or worse because there's no inventory of those requirements we should compare to, or is there?).

Now, don't get me wrong, these could have been the same reasons why we chose Typo3 in the first place (I don't know exactly what the requirements were back then, although I've heard the stories), but what I'm trying to say is that I wouldn't be inclined to switch from Typo3 to Github (or Hyde or Drupal or whatever new tool) just because it's there, does something (instead of all [reqs wanted]) or someone knows it better, unless we have a clear idea of what functionality we expect to support (and what we would be abandoning according to the choice we make). And if the final solution is to go with Typo3 (err, I mean, Jekyll), so let it be (and let's document our decisions so the Executive Committee in 10 years can also make an informed decision according to what we were considering today).

(P.S.: Please don't say we need a new logo, please don't say we need a new logo! ;-) )

mdoering commented 8 years ago

William, I'd say the key drive to put as much onto github is to be very open. Anyone has access to all the data immediately now and its archived.

WUlate commented 8 years ago

I agree, Markus; probably much more open and easier to share than other alternatives.
What I ask myself is if this should be our driving consideration now or if other requirements would outweigh this one in a sound decision? And I understand where we are coming from with our Typo3 solution, I won't say it's easy or the best, but it does have its qualities for some things, all of them do.
I just wished we could compare the tools coming against the reqs/functionality we need/want/wish (hopefully all of them, not just some; i.e. I would like to know also what we won't get from a solution) and then decide.

jmacklin commented 8 years ago

I agree that it would be wise to have some process here. This is a fairly major decision and we should weigh the cost/benefits based on our core use cases. And we do need to be as open as possible. Yes, no matter what there will be a learning curve but we do have the advantage that our community is pretty computer/IT/Informatics savvy :-)

Best, JAmes

On Thu, Feb 25, 2016 at 9:36 AM, WUlate notifications@github.com wrote:

I agree, Markus; probably much more open and easier to share than other alternatives.

What I ask myself is if this should be our driving consideration now or if other requirements would outweigh this one in a sound decision? And I understand where we are coming from with our Typo3 solution, I won't say it's easy or the best, but it does have its qualities for some things, all of them do.

I just wished we could compare the tools coming against the reqs/functionality we need/want/wish (hopefully all of them, not just some; i.e. I would like to know also what we won't get from a solution) and then decide.

— Reply to this email directly or view it on GitHub https://github.com/tdwg/infrastructure/issues/61#issuecomment-188812994.

stanblum commented 8 years ago

@mdoering (and all), I think GitHub actually provides several of the higher level functions there we were trying to support in the TDWG Infrastructure Project (TIP), including: repository, wiki, messaging among collaborators, and web site (where authoring is more controlled than a wiki). So I suggest we could begin by using the wiki capability (here in the infrastructure repo) to begin listing, organizing, analyzing the functional requirements. (I'll give it a try later today; need to prep for a call now.)

stanblum commented 8 years ago

I just turned on the wiki feature in this repository.

MattBlissett commented 4 years ago

Can this issue be closed?

stanblum commented 4 years ago

These decisions were made a long time ago, so, yes. Closing...