[OpenAFS] New OpenAFS website proposal.

Simon Wilkinson sxw@inf.ed.ac.uk
Fri, 26 Nov 2010 12:10:27 +0000


--Apple-Mail-1--1066383721
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> AFSLore Wiki was probably started with that idea but, frankly, it
> looks broken and inspires little confidence. There is also problem of
> repetition, with so many places to store relevant information, we risk
> them falling out of sync with each other.

We recently switched from TWiki to ikiwiki for the AFSLore content. Whilst t=
he content was all moved over, little has been done in terms of skinning tha=
t content. I suspect that it is this triumph of content over presentation th=
at makes you feel that it looks broken. The huge advantage of ikiwiki is tha=
t we can maintain it using the same tools as we use for our source and docum=
entation repositories.

We have a very small number of people looking after our infrastructure, and t=
heir time is pulled in many different directions. This means that simplicity=
, and reuse of existing tools, are both huge advantages for us. Obviously, i=
f there is an offer if ongoing maintenance then that shifts the balance a li=
ttle, but we do need to make sure that the site can survive the disappearanc=
e of any one person.

In my view, what we really need for the website is a new design - both visua=
l, and in terms of the information architecture. The choice of implementatio=
n technology should come second to this.

S.=

--Apple-Mail-1--1066383721
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><body bgcolor=3D"#FFFFFF"><div><br><font class=3D"Apple-style-span" co=
lor=3D"#0023A3"><font class=3D"Apple-style-span" color=3D"#000000"><br></fon=
t></font></div><blockquote type=3D"cite"><div><span>AFSLore Wiki was probabl=
y started with that idea but, frankly, it</span><br><span>looks broken and i=
nspires little confidence. There is also problem of</span><br><span>repetiti=
on, with so many places to store relevant information, we risk</span><br><sp=
an>them falling out of sync with each other.</span><br></div></blockquote><b=
r><div>We recently switched from TWiki to ikiwiki for the AFSLore content. W=
hilst the content was all moved over, little has been done in terms of skinn=
ing that content. I suspect that it is this triumph of content over presenta=
tion that makes you feel that it looks broken. The huge advantage of ikiwiki=
 is that we can maintain it using the same tools as we use for our source an=
d documentation repositories.</div><div><br></div><div>We have a very small n=
umber of people looking after our infrastructure, and their time is pulled i=
n many different directions. This means that simplicity, and reuse of existi=
ng tools, are both huge advantages for us. Obviously, if there is an offer i=
f ongoing maintenance then that shifts the balance a little, but we do need t=
o make sure that the site can survive the disappearance of any one person.</=
div><div><br></div><div>In my view, what we really need for the website is a=
 new design - both visual, and in terms of the information architecture. The=
 choice of implementation technology should come second to this.</div><div><=
br></div><div>S.</div></body></html>=

--Apple-Mail-1--1066383721--