Future of the Brand and Website
27 views
Skip to first unread message
James Thompson
Jun 15, 2016, 11:30:20 AM6/15/16
to sr...@googlegroups.com
Hello,
I'm pleased to announce several pieces of work that are now underway,
with the aim of consolidating the Student Robotics brand.
As SR continues to grow, it's important we make it easier to scale. It
should always be easy for teams and volunteers to identify official
information, and also know who we are and what we're about. On the other
side of this, for people representing SR, it shouldn't be onerous
producing this sort of information. It should be easy to do the right thing.
With that in mind, I've built the Student Robotics Style Guide:
https://srobo.github.io/style/
https://github.com/srobo/style/
It's a fairly loose set of guidelines and conventions around the use of
the Student Robotics brand, to the benefit of teams and volunteers.
The second piece of work, closely tied into the first, is the
re-development of the PR elements[1] of the Student Robotics website.
It's backed by Jekyll[2], and we're *not* looking to integrate it back
into srweb, or host it on Saffron. This is part of a larger plan to
break apart the various applications on Saffron and move them elsewhere.
There's still a lot of work to be done, and we need your help! You can
follow and contribute to development at:
https://srobo.github.io/website/
https://github.com/srobo/website/
If you have any questions, let me know. :-)
Cheers!
[1] This is the content which invites people to join Student Robotics.
This means *not* the team list, the docs, the forums, the IDE and
anything else with a purpose that isn't for publicity/PR.
[2] https://jekyllrb.com/
I'm pleased to announce several pieces of work that are now underway,
with the aim of consolidating the Student Robotics brand.
As SR continues to grow, it's important we make it easier to scale. It
should always be easy for teams and volunteers to identify official
information, and also know who we are and what we're about. On the other
side of this, for people representing SR, it shouldn't be onerous
producing this sort of information. It should be easy to do the right thing.
With that in mind, I've built the Student Robotics Style Guide:
https://srobo.github.io/style/
https://github.com/srobo/style/
It's a fairly loose set of guidelines and conventions around the use of
the Student Robotics brand, to the benefit of teams and volunteers.
The second piece of work, closely tied into the first, is the
re-development of the PR elements[1] of the Student Robotics website.
It's backed by Jekyll[2], and we're *not* looking to integrate it back
into srweb, or host it on Saffron. This is part of a larger plan to
break apart the various applications on Saffron and move them elsewhere.
There's still a lot of work to be done, and we need your help! You can
follow and contribute to development at:
https://srobo.github.io/website/
https://github.com/srobo/website/
If you have any questions, let me know. :-)
Cheers!
[1] This is the content which invites people to join Student Robotics.
This means *not* the team list, the docs, the forums, the IDE and
anything else with a purpose that isn't for publicity/PR.
[2] https://jekyllrb.com/
Peter Law
Jun 16, 2016, 3:44:07 PM6/16/16
to Student Robotics
Hi Jimmy,
> It
> should always be easy for teams and volunteers to identify official
> information, and also know who we are and what we're about.
> *snip*
https://www.studentrobotics.org/trac/wiki/House%20Style. There are a
number of things which have deviated from it over the years though, so
it's good to see that others are interested in trying to keep things
consistent.
Is there a reason to change the house font? It feels a little odd that
our logo uses one font yet our text uses something different.
I note that you're intending to change pretty much every aspect of the
style, albeit generally only slightly. Is there a list somewhere of
all the places (there are going to be a *lot*) which will need
updating to match the new style? Can people get involved with doing
this?
If we're going to change the colours I think it would also make sense
to review the logo as well:
- it's not symmetrical
- the point at the top is quite pronounced in comparison to the roundness
elsewhere (even though it's not very pointy in itself)
> It's a fairly loose set of guidelines and conventions around the use of
> the Student Robotics brand, to the benefit of teams and volunteers.
Is the plan that this would be included on the website, along with
suitable samples of the graphics? This would make it just as easy for
external entities (print/digital media, teams' blogs, schools'
websites, etc.) to use our asserts "properly" as our volunteers.
> The second piece of work, closely tied into the first, is the
> re-development of the PR elements[1] of the Student Robotics website.
I'd fairly strongly argue that the docs and teams information are part
of what get people interested in SR. A big part of what we do is that
we provide a kit to the teams, and that that kit is documented in
detail. While the docs themselves mostly aren't useful without the
kit, there are some aspects which are.
Similarly, part of the reason that we have the teams on our website is
that it shows who is involved as well as creating cross-linking
opportunities from their own blogs & websites, which in turn draw
attention to us. It's certainly less under our control, but it's a
much larger surface area than our own website has.
If the intent is that this new website won't include the docs/etc.,
where will each of those be kept and served from? How will we ensure
that they use a consistent template/look-and-feel to the main website?
> It's backed by Jekyll[2], and we're *not* looking to integrate it back
> into srweb,
Huh. There is a *lot* of valuable stuff in srweb which it would be a
shame to lose. The version history is fairly important, though I
suppose less valuable if everything's going to be rewritten; that
seems like a lot of effort however.
The most obvious thing which I think needs to be kept (along with its
version history) are the news articles. These appear to already have a
place in the new website, so it would seem silly not to move them
over.
There are a number of other pages which I think it's important to
keep; I've added to the issues in the github repo regarding these.
Another aspect is how our website interacts with search engines,
people's page-memory (in their heads), bookmarks & browser history.
If we change the URLs significantly there's going to be a long period
(I'd estimate a couple of *years* at least) where we see lots of
missed-pages. Having looked in piwik recently, I saw some urls which
mention the "slug" -- a technology we haven't used in over 6 years!
At the very least we need to have redirect pages to point people back
at content similar to that which they were looking for.
Separately, what's the plan for the competition pages? While part of
these is the /comp/* pages, the special homepage is also a big part of
it. These are very much more code than content (the content is
dynamic), so preserving their history is *very* important. Note that
these pages also rely on the SRComp HTTP API to function, so need to
be able to query that somehow.
> or host it on Saffron. This is part of a larger plan to
> break apart the various applications on Saffron and move them elsewhere.
Huh. Please could you expand on this? It sounds like you're suggesting
that we both:
- abandon the working server config we have
- separate out the many services SR has onto different hosts
One of the really useful features that we currently have is that it's
fairly easy to get a working copy of all of our hosting scenarios.
This includes saffron, though there are a number of independent VMs
(mostly competition things) which are configured in a similar way.
An important effect of this centralisation is that it's easy to build
a component which relies on other things elsewhere on the server,
since you can spin up the whole thing in one go and check it works.
If we wind up hosting things which need to interact with each other
from different places that seems like something which will become very
hard to check outside of the production environment.
This is perhaps something better suited to srobo-devel?
> There's still a lot of work to be done, and we need your help! You can
> follow and contribute to development at:
What's the time-frame for the migration -- is this planned for use
during SR2017? If so, are how certain are we that it's going to be
ready for use in SR2017 (i.e: less than 3 months from now [1])?
Thanks,
Peter
[1] SR2017 is underway already -- it stared on the 2nd May, after the
end of the competition, though I don't expect anyone to be using our
website until the run-up to Kickstart. If we assume a Kickstart date
of October 16th [2] then we don't want to be changing the website
during at least the preceding two weeks since teachers and teams will
be using it by then. Ideally we'd make the switch at least a month
ahead, giving us exactly three months to make that happen if it's
going to.
[2] October 16th was suggested in
http://thread.gmane.org/gmane.science.robotics.srobo.general/6637
> It
> should always be easy for teams and volunteers to identify official
> information, and also know who we are and what we're about.
>
> With that in mind, I've built the Student Robotics Style Guide:
In case you're not aware, we already have one of those:
> With that in mind, I've built the Student Robotics Style Guide:
https://www.studentrobotics.org/trac/wiki/House%20Style. There are a
number of things which have deviated from it over the years though, so
it's good to see that others are interested in trying to keep things
consistent.
Is there a reason to change the house font? It feels a little odd that
our logo uses one font yet our text uses something different.
I note that you're intending to change pretty much every aspect of the
style, albeit generally only slightly. Is there a list somewhere of
all the places (there are going to be a *lot*) which will need
updating to match the new style? Can people get involved with doing
this?
If we're going to change the colours I think it would also make sense
to review the logo as well:
- it's not symmetrical
- the point at the top is quite pronounced in comparison to the roundness
elsewhere (even though it's not very pointy in itself)
> It's a fairly loose set of guidelines and conventions around the use of
> the Student Robotics brand, to the benefit of teams and volunteers.
suitable samples of the graphics? This would make it just as easy for
external entities (print/digital media, teams' blogs, schools'
websites, etc.) to use our asserts "properly" as our volunteers.
> The second piece of work, closely tied into the first, is the
> re-development of the PR elements[1] of the Student Robotics website.
> [1] This is the content which invites people to join Student Robotics.
> This means *not* the team list, the docs...
I'd fairly strongly argue that the docs and teams information are part
of what get people interested in SR. A big part of what we do is that
we provide a kit to the teams, and that that kit is documented in
detail. While the docs themselves mostly aren't useful without the
kit, there are some aspects which are.
Similarly, part of the reason that we have the teams on our website is
that it shows who is involved as well as creating cross-linking
opportunities from their own blogs & websites, which in turn draw
attention to us. It's certainly less under our control, but it's a
much larger surface area than our own website has.
If the intent is that this new website won't include the docs/etc.,
where will each of those be kept and served from? How will we ensure
that they use a consistent template/look-and-feel to the main website?
> It's backed by Jekyll[2], and we're *not* looking to integrate it back
> into srweb,
shame to lose. The version history is fairly important, though I
suppose less valuable if everything's going to be rewritten; that
seems like a lot of effort however.
The most obvious thing which I think needs to be kept (along with its
version history) are the news articles. These appear to already have a
place in the new website, so it would seem silly not to move them
over.
There are a number of other pages which I think it's important to
keep; I've added to the issues in the github repo regarding these.
Another aspect is how our website interacts with search engines,
people's page-memory (in their heads), bookmarks & browser history.
If we change the URLs significantly there's going to be a long period
(I'd estimate a couple of *years* at least) where we see lots of
missed-pages. Having looked in piwik recently, I saw some urls which
mention the "slug" -- a technology we haven't used in over 6 years!
At the very least we need to have redirect pages to point people back
at content similar to that which they were looking for.
Separately, what's the plan for the competition pages? While part of
these is the /comp/* pages, the special homepage is also a big part of
it. These are very much more code than content (the content is
dynamic), so preserving their history is *very* important. Note that
these pages also rely on the SRComp HTTP API to function, so need to
be able to query that somehow.
> or host it on Saffron. This is part of a larger plan to
> break apart the various applications on Saffron and move them elsewhere.
that we both:
- abandon the working server config we have
- separate out the many services SR has onto different hosts
One of the really useful features that we currently have is that it's
fairly easy to get a working copy of all of our hosting scenarios.
This includes saffron, though there are a number of independent VMs
(mostly competition things) which are configured in a similar way.
An important effect of this centralisation is that it's easy to build
a component which relies on other things elsewhere on the server,
since you can spin up the whole thing in one go and check it works.
If we wind up hosting things which need to interact with each other
from different places that seems like something which will become very
hard to check outside of the production environment.
This is perhaps something better suited to srobo-devel?
> There's still a lot of work to be done, and we need your help! You can
> follow and contribute to development at:
during SR2017? If so, are how certain are we that it's going to be
ready for use in SR2017 (i.e: less than 3 months from now [1])?
Thanks,
Peter
[1] SR2017 is underway already -- it stared on the 2nd May, after the
end of the competition, though I don't expect anyone to be using our
website until the run-up to Kickstart. If we assume a Kickstart date
of October 16th [2] then we don't want to be changing the website
during at least the preceding two weeks since teachers and teams will
be using it by then. Ideally we'd make the switch at least a month
ahead, giving us exactly three months to make that happen if it's
going to.
[2] October 16th was suggested in
http://thread.gmane.org/gmane.science.robotics.srobo.general/6637
Rob Spanton
Jun 16, 2016, 4:28:44 PM6/16/16
to sr...@googlegroups.com
Hey Jimmy,
On Wed, 2016-06-15 at 16:30 +0100, James Thompson wrote:
> With that in mind, I've built the Student Robotics Style Guide:
>
> ...
Cheers,
Rob
On Wed, 2016-06-15 at 16:30 +0100, James Thompson wrote:
> With that in mind, I've built the Student Robotics Style Guide:
>
>
> The second piece of work, closely tied into the first, is the
> re-development of the PR elements[1] of the Student Robotics website.
Wup wup! Thanks Jimmy!
> The second piece of work, closely tied into the first, is the
> re-development of the PR elements[1] of the Student Robotics website.
Cheers,
Rob
James Thompson
Jun 22, 2016, 5:25:33 PM6/22/16
to sr...@googlegroups.com
Hey Peter,
> In case you're not aware, we already have one of those:
> https://www.studentrobotics.org/trac/wiki/House%20Style. There are a
> number of things which have deviated from it over the years though, so
> it's good to see that others are interested in trying to keep things
> consistent.
The Style Guide is based on that very page, and is intended to replace
it. The hope is that we can move towards a sort of "living" style guide
with packaged SASS/CSS[1], so it becomes easier to produce web
applications using the brand.
> Is there a reason to change the house font? It feels a little odd that
> our logo uses one font yet our text uses something different.
The main issue with Eurostile is the licence. There's a small mire of
issues around licencing Eurostile for the logo, for the web, and
physical content. It might be worth investing in licencing the logo
alone, but the others didn't feel worth it. Oswald and Open Sans remove
a lot of the licencing problems, and having separate logo and header
fonts isn't that uncommon.
> I note that you're intending to change pretty much every aspect of the
> style, albeit generally only slightly. Is there a list somewhere of
> all the places (there are going to be a *lot*) which will need
> updating to match the new style? Can people get involved with doing
> this?
I've not prepared a list just yet. Right now my focus is getting the new
website side-by-side with srweb, but I'd be delighted if parts of SR
were brought up to date with the new style during that time.
> If we're going to change the colours I think it would also make sense
> to review the logo as well:
> - it's not symmetrical
> - the point at the top is quite pronounced in comparison to the roundness
> elsewhere (even though it's not very pointy in itself)
I am not really interested in changing the logo, but if you do some work
and it looks good, I wouldn't be opposed to updating it, provided it
doesn't depart too far from the existing one.
> Is the plan that this would be included on the website, along with
> suitable samples of the graphics? This would make it just as easy for
> external entities (print/digital media, teams' blogs, schools'
> websites, etc.) to use our asserts "properly" as our volunteers.
Good idea! I'd not thought of that.
> I'd fairly strongly argue that the docs and teams information are part
> of what get people interested in SR. A big part of what we do is that
> we provide a kit to the teams, and that that kit is documented in
> detail. While the docs themselves mostly aren't useful without the
> kit, there are some aspects which are.
>
> Similarly, part of the reason that we have the teams on our website is
> that it shows who is involved as well as creating cross-linking
> opportunities from their own blogs & websites, which in turn draw
> attention to us. It's certainly less under our control, but it's a
> much larger surface area than our own website has.
>
> If the intent is that this new website won't include the docs/etc.,
> where will each of those be kept and served from? How will we ensure
> that they use a consistent template/look-and-feel to the main website?
I agree that the docs and the team pages do get people interested in SR,
but unlike the "PR" parts of the site I'm not responsible for them.
As far as where they live and where they're hosted, as far as I'm aware
it's still in srweb until someone says otherwise. The migration plan, as
it stands, is to have some sort of reverse proxy (e.g. nginx) funnelling
requests between where the new PR site is hosted (likely some static
file host like S3) and the existing srweb.
I'll be pushing to bringing other parts of the site up-to-date with the
new style.
> Huh. There is a *lot* of valuable stuff in srweb which it would be a
> shame to lose. The version history is fairly important, though I
> suppose less valuable if everything's going to be rewritten; that
> seems like a lot of effort however.
>
> The most obvious thing which I think needs to be kept (along with its
> version history) are the news articles. These appear to already have a
> place in the new website, so it would seem silly not to move them
> over.
I don't intend for the srweb repository to disappear, as a source of
history it's invaluable.
I agree that news articles should be moved over.
> There are a number of other pages which I think it's important to
> keep; I've added to the issues in the github repo regarding these.
>
> Another aspect is how our website interacts with search engines,
> people's page-memory (in their heads), bookmarks & browser history.
> If we change the URLs significantly there's going to be a long period
> (I'd estimate a couple of *years* at least) where we see lots of
> missed-pages. Having looked in piwik recently, I saw some urls which
> mention the "slug" -- a technology we haven't used in over 6 years!
>
> At the very least we need to have redirect pages to point people back
> at content similar to that which they were looking for.
I downloaded all the urls requested in the past two years from Piwik,
and I plan on picking a view count cut-off for links which I think
should be preserved.
The important pages which have a new URL (e.g. how to enter) I
definitely want to redirect.
> Separately, what's the plan for the competition pages? While part of
> these is the /comp/* pages, the special homepage is also a big part of
> it. These are very much more code than content (the content is
> dynamic), so preserving their history is *very* important. Note that
> these pages also rely on the SRComp HTTP API to function, so need to
> be able to query that somehow.
Not sure how this will work at the moment. Assuming it ends up going
into this website (and not a separate competition app), I /guess/ XHR
requests to the SRComp API to work since they should both be on the same
domain, unless I'm mistaken.
> Huh. Please could you expand on this? It sounds like you're suggesting
> that we both:
> - abandon the working server config we have
> - separate out the many services SR has onto different hosts
>
> One of the really useful features that we currently have is that it's
> fairly easy to get a working copy of all of our hosting scenarios.
> This includes saffron, though there are a number of independent VMs
> (mostly competition things) which are configured in a similar way.
>
> An important effect of this centralisation is that it's easy to build
> a component which relies on other things elsewhere on the server,
> since you can spin up the whole thing in one go and check it works.
> If we wind up hosting things which need to interact with each other
> from different places that seems like something which will become very
> hard to check outside of the production environment.
>
> This is perhaps something better suited to srobo-devel?
That may not be exactly how it ends up, but that's the intention, yes.
I'm sure it will be more pragmatic than it sounds, but for this website
work, which is entirely static content, I think it makes sense.
This probably is a discussion better suited for srobo-devel.
> What's the time-frame for the migration -- is this planned for use
> during SR2017? If so, are how certain are we that it's going to be
> ready for use in SR2017 (i.e: less than 3 months from now [1])?
Hopefully it should be ready before Kickstart, but I agree, it shouldn't
interfere with the competition if it is delayed. Your deadline of two
weeks before Kickstart is sensible. I'm fairly confident we can deploy
it before then, but most of us have other things, so I can't swear on it.
Cheers,
Jimmy
[1] Inspired by https://style.codeforamerica.org/ and many others.
> In case you're not aware, we already have one of those:
> https://www.studentrobotics.org/trac/wiki/House%20Style. There are a
> number of things which have deviated from it over the years though, so
> it's good to see that others are interested in trying to keep things
> consistent.
it. The hope is that we can move towards a sort of "living" style guide
with packaged SASS/CSS[1], so it becomes easier to produce web
applications using the brand.
> Is there a reason to change the house font? It feels a little odd that
> our logo uses one font yet our text uses something different.
issues around licencing Eurostile for the logo, for the web, and
physical content. It might be worth investing in licencing the logo
alone, but the others didn't feel worth it. Oswald and Open Sans remove
a lot of the licencing problems, and having separate logo and header
fonts isn't that uncommon.
> I note that you're intending to change pretty much every aspect of the
> style, albeit generally only slightly. Is there a list somewhere of
> all the places (there are going to be a *lot*) which will need
> updating to match the new style? Can people get involved with doing
> this?
website side-by-side with srweb, but I'd be delighted if parts of SR
were brought up to date with the new style during that time.
> If we're going to change the colours I think it would also make sense
> to review the logo as well:
> - it's not symmetrical
> - the point at the top is quite pronounced in comparison to the roundness
> elsewhere (even though it's not very pointy in itself)
and it looks good, I wouldn't be opposed to updating it, provided it
doesn't depart too far from the existing one.
> Is the plan that this would be included on the website, along with
> suitable samples of the graphics? This would make it just as easy for
> external entities (print/digital media, teams' blogs, schools'
> websites, etc.) to use our asserts "properly" as our volunteers.
> I'd fairly strongly argue that the docs and teams information are part
> of what get people interested in SR. A big part of what we do is that
> we provide a kit to the teams, and that that kit is documented in
> detail. While the docs themselves mostly aren't useful without the
> kit, there are some aspects which are.
>
> Similarly, part of the reason that we have the teams on our website is
> that it shows who is involved as well as creating cross-linking
> opportunities from their own blogs & websites, which in turn draw
> attention to us. It's certainly less under our control, but it's a
> much larger surface area than our own website has.
>
> If the intent is that this new website won't include the docs/etc.,
> where will each of those be kept and served from? How will we ensure
> that they use a consistent template/look-and-feel to the main website?
but unlike the "PR" parts of the site I'm not responsible for them.
As far as where they live and where they're hosted, as far as I'm aware
it's still in srweb until someone says otherwise. The migration plan, as
it stands, is to have some sort of reverse proxy (e.g. nginx) funnelling
requests between where the new PR site is hosted (likely some static
file host like S3) and the existing srweb.
I'll be pushing to bringing other parts of the site up-to-date with the
new style.
> Huh. There is a *lot* of valuable stuff in srweb which it would be a
> shame to lose. The version history is fairly important, though I
> suppose less valuable if everything's going to be rewritten; that
> seems like a lot of effort however.
>
> The most obvious thing which I think needs to be kept (along with its
> version history) are the news articles. These appear to already have a
> place in the new website, so it would seem silly not to move them
> over.
history it's invaluable.
I agree that news articles should be moved over.
> There are a number of other pages which I think it's important to
> keep; I've added to the issues in the github repo regarding these.
>
> Another aspect is how our website interacts with search engines,
> people's page-memory (in their heads), bookmarks & browser history.
> If we change the URLs significantly there's going to be a long period
> (I'd estimate a couple of *years* at least) where we see lots of
> missed-pages. Having looked in piwik recently, I saw some urls which
> mention the "slug" -- a technology we haven't used in over 6 years!
>
> At the very least we need to have redirect pages to point people back
> at content similar to that which they were looking for.
and I plan on picking a view count cut-off for links which I think
should be preserved.
The important pages which have a new URL (e.g. how to enter) I
definitely want to redirect.
> Separately, what's the plan for the competition pages? While part of
> these is the /comp/* pages, the special homepage is also a big part of
> it. These are very much more code than content (the content is
> dynamic), so preserving their history is *very* important. Note that
> these pages also rely on the SRComp HTTP API to function, so need to
> be able to query that somehow.
into this website (and not a separate competition app), I /guess/ XHR
requests to the SRComp API to work since they should both be on the same
domain, unless I'm mistaken.
> Huh. Please could you expand on this? It sounds like you're suggesting
> that we both:
> - abandon the working server config we have
> - separate out the many services SR has onto different hosts
>
> One of the really useful features that we currently have is that it's
> fairly easy to get a working copy of all of our hosting scenarios.
> This includes saffron, though there are a number of independent VMs
> (mostly competition things) which are configured in a similar way.
>
> An important effect of this centralisation is that it's easy to build
> a component which relies on other things elsewhere on the server,
> since you can spin up the whole thing in one go and check it works.
> If we wind up hosting things which need to interact with each other
> from different places that seems like something which will become very
> hard to check outside of the production environment.
>
> This is perhaps something better suited to srobo-devel?
I'm sure it will be more pragmatic than it sounds, but for this website
work, which is entirely static content, I think it makes sense.
This probably is a discussion better suited for srobo-devel.
> What's the time-frame for the migration -- is this planned for use
> during SR2017? If so, are how certain are we that it's going to be
> ready for use in SR2017 (i.e: less than 3 months from now [1])?
interfere with the competition if it is delayed. Your deadline of two
weeks before Kickstart is sensible. I'm fairly confident we can deploy
it before then, but most of us have other things, so I can't swear on it.
Cheers,
Jimmy
[1] Inspired by https://style.codeforamerica.org/ and many others.
Peter Law
Jul 3, 2016, 11:33:18 AM7/3/16
to Student Robotics
Hi,
I wrote:
>> If we're going to change the colours I think it would also make sense
>> to review the logo as well:
>> - it's not symmetrical
>> - the point at the top is quite pronounced in comparison to the roundness
>> elsewhere (even though it's not very pointy in itself)
it definitely shouldn't change too much!
I don't have any time to look at this, and it's not entirely urgent
(we've managed for 7 years with it), but might be a useful quick
contribution for someone.
Thanks,
Peter
I wrote:
>> If we're going to change the colours I think it would also make sense
>> to review the logo as well:
>> - it's not symmetrical
>> - the point at the top is quite pronounced in comparison to the roundness
>> elsewhere (even though it's not very pointy in itself)
Jimmy wrote:
> I am not really interested in changing the logo, but if you do some work
> and it looks good, I wouldn't be opposed to updating it, provided it
> doesn't depart too far from the existing one.
My intention here was merely that we tidy the existing one -- I think
> I am not really interested in changing the logo, but if you do some work
> and it looks good, I wouldn't be opposed to updating it, provided it
> doesn't depart too far from the existing one.
it definitely shouldn't change too much!
I don't have any time to look at this, and it's not entirely urgent
(we've managed for 7 years with it), but might be a useful quick
contribution for someone.
Thanks,
Peter
Peter Law
Jul 3, 2016, 12:40:49 PM7/3/16
to Student Robotics
Hi,
>> I'd fairly strongly argue that the docs and teams information are part
>> of what get people interested in SR. A big part of what we do is that
>> we provide a kit to the teams, and that that kit is documented in
>> detail. While the docs themselves mostly aren't useful without the
>> kit, there are some aspects which are.
>>
>> Similarly, part of the reason that we have the teams on our website is
>> that it shows who is involved as well as creating cross-linking
>> opportunities from their own blogs & websites, which in turn draw
>> attention to us. It's certainly less under our control, but it's a
>> much larger surface area than our own website has.
>>
>> If the intent is that this new website won't include the docs/etc.,
>> where will each of those be kept and served from? How will we ensure
>> that they use a consistent template/look-and-feel to the main website?
>
> I agree that the docs and the team pages do get people interested in SR,
> but unlike the "PR" parts of the site I'm not responsible for them.
Umm, this seems a very silo-ish approach which appears likely to
result in lower cohesion between the parts, patchy support for things
and stuff being lost "down the cracks". I would note that historically
the holistic approach SR has allowed for things such as the website
has benefited it greatly.
>> What's the time-frame for the migration -- is this planned for use
>> during SR2017? If so, are how certain are we that it's going to be
>> ready for use in SR2017 (i.e: less than 3 months from now [1])?
>
> Hopefully it should be ready before Kickstart, but I agree, it shouldn't
> interfere with the competition if it is delayed. Your deadline of two
> weeks before Kickstart is sensible. I'm fairly confident we can deploy
> it before then, but most of us have other things, so I can't swear on it.
To be clear, my intent with the "two weeks before Kickstart" was a ballpark
estimate on the the latest point at which the migration should be fully
complete. I would suggest that we should take a view on progress at *least*
two weeks before that to determine whether the switch should happen for this
year.
I would greatly appreciate some input from Jeremy on whether two weeks
ahead of Kickstart is far enough back with regards to when the
team-leaders start wanting to look stuff up on our website/we start
pointing them at it.
Thanks,
Peter
PS: I've migrated the other, more technical aspects of this disucsion
to srobo-devel:
https://groups.google.com/d/topic/srobo-devel/jSjEKYE0jo8/discussion
>> I'd fairly strongly argue that the docs and teams information are part
>> of what get people interested in SR. A big part of what we do is that
>> we provide a kit to the teams, and that that kit is documented in
>> detail. While the docs themselves mostly aren't useful without the
>> kit, there are some aspects which are.
>>
>> Similarly, part of the reason that we have the teams on our website is
>> that it shows who is involved as well as creating cross-linking
>> opportunities from their own blogs & websites, which in turn draw
>> attention to us. It's certainly less under our control, but it's a
>> much larger surface area than our own website has.
>>
>> If the intent is that this new website won't include the docs/etc.,
>> where will each of those be kept and served from? How will we ensure
>> that they use a consistent template/look-and-feel to the main website?
>
> I agree that the docs and the team pages do get people interested in SR,
> but unlike the "PR" parts of the site I'm not responsible for them.
result in lower cohesion between the parts, patchy support for things
and stuff being lost "down the cracks". I would note that historically
the holistic approach SR has allowed for things such as the website
has benefited it greatly.
>> What's the time-frame for the migration -- is this planned for use
>> during SR2017? If so, are how certain are we that it's going to be
>> ready for use in SR2017 (i.e: less than 3 months from now [1])?
>
> Hopefully it should be ready before Kickstart, but I agree, it shouldn't
> interfere with the competition if it is delayed. Your deadline of two
> weeks before Kickstart is sensible. I'm fairly confident we can deploy
> it before then, but most of us have other things, so I can't swear on it.
estimate on the the latest point at which the migration should be fully
complete. I would suggest that we should take a view on progress at *least*
two weeks before that to determine whether the switch should happen for this
year.
I would greatly appreciate some input from Jeremy on whether two weeks
ahead of Kickstart is far enough back with regards to when the
team-leaders start wanting to look stuff up on our website/we start
pointing them at it.
Thanks,
Peter
PS: I've migrated the other, more technical aspects of this disucsion
to srobo-devel:
https://groups.google.com/d/topic/srobo-devel/jSjEKYE0jo8/discussion
Reply all
Reply to author
Forward
0 new messages