Release notes link on website wrong
Gerry Patterson
The link for the release notes of 0.8.0 on the website for Hugin http://hugin.sourceforge.net/ is pointing to 0.7.0. This should probably be updated.
- Gerry
Bart van Andel
screenshots are all pretty outdated, and maybe a cleaner design would
be nice too.
I played with GIMP a bit and this is what I came up with:
http://hugin-ptx.googlegroups.com/web/2009.07.19+Hugin+website+mockup.jpg?gda=AAyq31UAAAB5WCHnJ36RA1_o8HGXLskrEPu-gxI1fsj-99Dw4NtK4e37Qu03NwfuOmwDARaTK9Dt3oZumLZY_Q5b4qjS3WAdc5ap1mUA98uo2agjH0hUOhrtYix3qocOGWUY90Yyf_g
(I hope this terribly long URL works, the file is uploaded to this
group). What do you think?
--
Bart
Bart van Andel
working some more on it. File is here (right click, save as):
http://groups.google.com/group/hugin-ptx/web/2009.07.19%20Hugin%20website%20mockup.xcf
Fonts used (probably not all available for web, but anyway):
- logo line: DejaVu Sans Bold
- headings: DejaVu Serif
- texts: Georgia
- screenshot caption: Georgia Italic
--
Bart
On 19 jul, 20:57, Bart van Andel <bavanan...@gmail.com> wrote:
> I think the website needs a little polish for other things too. The
> screenshots are all pretty outdated, and maybe a cleaner design would
> be nice too.
> I played with GIMP a bit and this is what I came up with:
>
Gerry Patterson
On Jul 19, 2009, at 2:06 PM, Bart van Andel <bavan...@gmail.com>
wrote:
Hi
This is very pretty although I am guess it it is a matter of available
time that Bruno? has. How does one go about making changes to the
website?
Gerry
Yuval Levy
> This is very pretty although I am guess it it is a matter of available
> time that Bruno? has. How does one go about making changes to the
> website?
http://hugin.svn.sourceforge.net/viewvc/hugin/htdocs/
all you need is SVN write access, fetch the above folder from SVN, make
any changes you deem necessary and upload back to SVN. Bruno has set up
a script that updates the website regularly (every hour?) from SVN.
@Bart: what is your Sourceforge handle? I think we should give you SVN
write access :)
Yuv
Bruno Postle
>On Jul 19, 2009, at 2:06 PM, Bart van Andel <bavan...@gmail.com> wrote:
>
>> Just uploaded the GIMP .xcf as well, in case someone feels like
>> working some more on it. File is here (right click, save as):
>>
>> http://groups.google.com/group/hugin-ptx/web/2009.07.19%20Hugin%20website%20mockup.xcf
>This is very pretty although I am guess it it is a matter of available
>time that Bruno? has. How does one go about making changes to the
>website?
Yes the design is tired and this looks like a nice change, the only
thing I would prefer not to fade the panorama at the top, as it is a
showcase of hugin itself.
(we could use lots more of these banners, they need to be 165 pixels
high, tile horizontally and be done with hugin)
The pages are simple XHTML with SSI and CSS for navigation and
styling. I don't have the time to work on applying a new style so
we really need the new CSS and any images complete.
The screenshot on the main page is five years old, this desperately
needs updating, and we need some more showing features and languages
on the /screenshots/ page.
The site is in SVN, changes are synchronised to the live site every
hour so no need to ask my permission to make changes:
https://hugin.svn.sourceforge.net/svnroot/hugin/htdocs/
There is a bit of dynamic stuff going on: the panorama banners are
rotated randomly every hour, the news on the front page is
derived from the sourceforge project news every six hours, and the
/docs/html/ doxygen docs are updated nightly.
The news section can be shortened some more, but I'd need to rewrite
the script that fetches it, I'll it here if anyone wants to work on
this.
--
Bruno
Tduell
On Jul 20, 9:28 am, Bruno Postle <br...@postle.net> wrote:
[snip]
> Yes the design is tired and this looks like a nice change, the only
> thing I would prefer not to fade the panorama at the top, as it is a
> showcase of hugin itself.
Having built a couple of tutorials using the existing webpage style I
can say that it is pretty simple to generate a new page/tutorial etc
when the basic style uses a plane background, i.e. drop images into
the page wherever it suits and it still keeps the look of the home
page. The new design offering looks a tad more complex with a
different background behind the images. There may be easy ways of
maintaining this style across new pages, I'm not sure. I guess it
depends on the detail of how it's done, and maybe it isn't necessary
to always mimick all aspects of the appearance/style of the home page.
The above isn't meant to be criticism of the proposed design, just
pointing out that the effort required to update the existing pages and
building new pages in a new style is worth keeping in mind...and a bit
of thinking out loud.
I am willing to put time into converting existing pages to any new
design, if needed.
Cheers,
Terry
Yuval Levy
> (we could use lots more of these banners, they need to be 165 pixels
> high, tile horizontally and be done with hugin)
<http://panospace.wordpress.com/2009/07/20/hugins-homepage-refresher/>
Yuv
Bart van Andel
create one. I can probably do this tomorrow, I really should go catch
some sleep now (why am I still here, am I becoming an addict?)
--
Bart
Bart van Andel
> Yes the design is tired and this looks like a nice change, the only
> thing I would prefer not to fade the panorama at the top, as it is a
> showcase of hugin itself.
of space, moving the other content a bit too far down. I felt it looks
a lot more attractive like this. I made it a bit brighter so the title
can be put on top and still be readable, and the fadeout gives room
for the menu. But I'll see into other solutions (if there are other
creative GIMP'ers around, please show your ideas too!).
> (we could use lots more of these banners, they need to be 165 pixels
> high, tile horizontally and be done with hugin)
this might change, so maybe we might want them at double resolution so
they can be safely scaled down when needed.
> The pages are simple XHTML with SSI and CSS for navigation and
> styling. I don't have the time to work on applying a new style so
> we really need the new CSS and any images complete.
usage (like php and mysql). This could ease the web design.
See http://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web
> The screenshot on the main page is five years old, this desperately
> needs updating, and we need some more showing features and languages
> on the /screenshots/ page.
definitely add value to the look and feel of the design.
> The site is in SVN, changes are synchronised to the live site every
> hour so no need to ask my permission to make changes:
>
> https://hugin.svn.sourceforge.net/svnroot/hugin/htdocs/
>
> There is a bit of dynamic stuff going on: the panorama banners are
> rotated randomly every hour, the news on the front page is
> derived from the sourceforge project news every six hours, and the
> /docs/html/ doxygen docs are updated nightly.
>
> The news section can be shortened some more, but I'd need to rewrite
> the script that fetches it, I'll it here if anyone wants to work on
> this.
by the website itself when using (e.g.) php, showing a different
banner every refresh, for instance. I guess a php news ticker can also
automatically import news from the project page, or even read it
directly from the project news database.
Static html is sooo 2004 ;-)
--
Bart
Bart van Andel
with the new design (I'm not saying it will but it might). Uploading
them a bit larger (330 pixels high for example) gives us the chance to
downsize them without real quality loss appropriately. If agreed,
could you change the text on your blog accordingly?
--
Bart
Yuval Levy
> I see that sf.net also supports server-side scripting and database
> usage (like php and mysql). This could ease the web design.
> See http://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web
historically the SF infrastructure has been a victim of its own success
and mostly underpowered / slow. The least we use of these stuff, the
more chances we have to have a decent responsive website.
> Do we want standard sizes for the screenshots? A standard will
> definitely add value to the look and feel of the design.
+1 - and also a standard cropping/scaling.
how about capturing all screenshots at 1024x768? (I was actually
thinking of 1024x600 = netbook, but many screens don't fit)
the web designer (hey, where is your SF handle so that we can give you
access?) will determine the design that will determine the scaling factor.
> I see the images are rotated by a shell script now, this could be done
> by the website itself when using (e.g.) php
+1 for PHP
> Static html is sooo 2004 ;-)
and the law of gravity is soooo 1687 ;-)
and Bart van Andel wrote also:
> Like I said above, 165 pixels is for the old design. This might change
> with the new design (I'm not saying it will but it might). Uploading
> them a bit larger (330 pixels high for example) gives us the chance to
> downsize them without real quality loss appropriately. If agreed,
> could you change the text on your blog accordingly?
sure. I just wanted to get some buzz going. more important than the
pixel dimension would be IMO to give proper credit to the artist.
I am a little bit skeptical about giving up display real-estate from
content (i.e. Hugin information) to aesthetic. For the purpose of simply
displying large images there is Flickr (and maybe just plugging in there
Flickr images would be an idea?)
Yuv
Bruno Postle
>
>I see that sf.net also supports server-side scripting and database
>usage (like php and mysql). This could ease the web design.
>See http://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web
The sourceforge servers have great bandwidth, but are utterly
unreliable for stuff like mysql. All the dynamic stuff was moved to
another server which then updates the live site via rsync.
>> The screenshot on the main page is five years old, this desperately
>> needs updating, and we need some more showing features and languages
>> on the /screenshots/ page.
>
>Do we want standard sizes for the screenshots? A standard will
>definitely add value to the look and feel of the design.
The older tutorials have 600 pixel wide images and the newer ones
have 800 pixel wide images. With the current CSS margins these
800 pixel images are ok on a 1024x768 display.
>I see the images are rotated by a shell script now, this could be done
>by the website itself when using (e.g.) php, showing a different
>banner every refresh, for instance.
We used to have that but it is very distracting.
>I guess a php news ticker can also automatically import news from
>the project page, or even read it directly from the project news
>database.
Good luck, the sourceforge newsfeed is basically garbage, hence the
munging in the hugin-news script.
>Static html is sooo 2004 ;-)
..but it works. Look at the tutorial pages in SVN, these are very
simple and easy for non-web-designers to create and edit - Though
admittedly a wiki would be better.
The current web-site has complete separation between style and
content, it is possible to overhaul the design entirely with CSS.
--
Bruno
Tduell
> simple and easy for non-web-designers to create and edit - Though
> admittedly a wiki would be better.
>
> The current web-site has complete separation between style and
> content, it is possible to overhaul the design entirely with CSS.
I know very little about design/generation of web pages but found it
quite easy to build a number of tutorials.
If we change the web site to the extent that simple folk like me need
special skills/tools to build a new tutorial page in the house style,
then I will find it difficult to contribute.
Building tutorial pages is about the only way I can readily
contribute, so let's try to keep it simple while we smarten up the
look.
Just another two bobs worth.
Cheers,
Terry
Bart van Andel
- The new design will be fresh and clear.
- PHP will be used to display most content, including news and the
header. I'll see what I can do about the sf news feed being garbage.
If only I could talk with the db directly, this might be solved
easily, but I have to investigate this.
- I still have to figure out a way to display the header nicely
without having all other content shift as far down as it does with the
current design. I like what I did in the mockup, but I understand
Bruno's point about the header being a showcase for Hugin.
- I agree with Bruno that loading a new header image on every refresh
will probably be too distractive. However, I'd like the ability to
show more images when the user asks for it. Proposed solution: two
small links somewhere on the header akin to "show previous / next
header". The links could be smaller (preferably, to minimize clutter)
if a mouseover or tooltip is used.
- For consistency, we'll use screenshots taken at a standard
resolution. Yuv suggested a size of 1024x768 (4:3 aspect ratio), which
I think is a good compromize. On the other hand we might want to show
how Hugin looks on a wide screen too (16:9 aspect ratio). They could
be categorized if that's appropriate.
- Terry expresses his concern about a dynamic website (think php)
increasing the difficulty to create tutorials. I am aware that this
should stay as easy as possible, and using static HTML for tutorials
is no problem at all. I can have them included using php code, or
loaded in an iframe, or better: use a wiki. KISS is the word.
Question: what about the panotools wiki? Maybe we could put tutorials
there and link from (and show them within) the Hugin site?
Maybe some of you have seen the Google video about their new upcoming
Wave thing. I think this could be the next step for tutorials and the
like (and perhaps even this list). In case you missed it: see
http://wave.google.com/
--
Bart
Yuval Levy
> - PHP will be used to display most content
please don't. I hate to be the one to damp your enthusiasm, but you have
to understand the limits of the current hosting environment.
you can use javascript (i.e. client side gimicks), and you can use PHP
scripts to empower users to contribute images to the gallery and so, but
please make sure your PHP generates static pages.
also the website should be easy to maintain, i.e. most of what is visual
/ design should be done in CSS.
I know where you are coming from, and I am a fan of web based PHP apps
(you've uploaded to http://www.uwivi.com/, right?), and I am sure you
could do magic. But it won't be useful in the current hosting environment.
> - I agree with Bruno that loading a new header image on every refresh
> will probably be too distractive. However, I'd like the ability to
> show more images
actually a different image on every refresh is not distractive at all
IMO. panoguide.com and ivrpa.org are good examples.
and if you want to do PHP magic, there could be a "staging server" where
people can upload/add images, and that staging server would generate the
static stuff that goes live on SourceForge (and Javascript could do the
random rotating thing).
> we might want to show
> how Hugin looks on a wide screen too (16:9 aspect ratio).
the future is wide screen, go for it and forget my suggestion.
> Question: what about the panotools wiki? Maybe we could put tutorials
> there and link from (and show them within) the Hugin site?
great idea! it is a lot of effort to migrate the tutorials there, but
long term it's the natural choice. Not sure about the showing within the
site, but I'm confident you'll find a solution that works.
> Maybe some of you have seen the Google video about their new upcoming
> Wave thing. I think this could be the next step for tutorials and the
> like (and perhaps even this list). In case you missed it: see
> http://wave.google.com/
for now we work with the tools that exist. when wave is available, it
will be properly analyzed / considered.
Yuv
Bart van Andel
> Bart van Andel wrote:
> > - PHP will be used to display most content
>
> please don't. I hate to be the one to damp your enthusiasm, but you have
> to understand the limits of the current hosting environment.
>
> you can use javascript (i.e. client side gimicks), and you can use PHP
> scripts to empower users to contribute images to the gallery and so, but
> please make sure your PHP generates static pages.
It's not about gimmicks at all (which should go into js indeed). PHP
just eases the process of adding a menu to each page, and rotating
header images, for example. When something in the menu changes, only
the menu include file should have to be changed, instead of every
single html file that uses it.
I just browsed around sf.net for a bit and found php not to be as
nasty as some people seem to think here, just take a look at
http://azureus.sourceforge.net/ for example. It's fast.
> also the website should be easy to maintain, i.e. most of what is visual
> / design should be done in CSS.
always be separated as much as possible. IMHO, styling inside html has
been deprecated mostly since CSS was invented.
> actually a different image on every refresh is not distractive at all
> IMO. panoguide.com and ivrpa.org are good examples.
about it. Of course I could just add the feature and see if it
distracts when the page is up and running. Disabling it again won't be
much trouble.
> and if you want to do PHP magic, there could be a "staging server" where
> people can upload/add images, and that staging server would generate the
> static stuff that goes live on SourceForge (and Javascript could do the
> random rotating thing).
same as using php, templates and a cache with compiled / parsed
templates, which is not very difficult to do. If the templates are
kept simple (my intention) the php overhead is pretty small anyway
(just some str_replace or ?reg_replace calls). I wasn't going to
introduce heavy php scripting, just some simple stuff to ease the site
building.
Maybe all the fuss about sf.net being slow on php is something of the
past. What is this fuss based on?
--
Bart
Bruno Postle
>It's not about gimmicks at all (which should go into js indeed). PHP
>just eases the process of adding a menu to each page, and rotating
>header images, for example. When something in the menu changes, only
>the menu include file should have to be changed, instead of every
>single html file that uses it.
..this is what SSI does, you don't need a programming language to
separate navigation from content in a web page.
The header image is a CSS background. If you want to deliver a
random image, the place to do it is not by rewriting the page every
time it is called, but by supplying a different image every time the
image is fetched.
I'm really keen that you do this, but from my perspective the things
that are wrong with the web-site are that: the look is old, and the
content is even older. The technology used to deliver it just isn't
a problem and is very maintainable (though a full CMS or wiki would
be ok too).
--
Bruno
Gerry Patterson
So back to the original post, the link in the news section for the 0.8.0 release still points to the 0.7.0 release notes. I checked out the htdocs directory, but that information is pulled from the news forum feed on sourceforge. I do not appear to have access to edit the entries in the sourceforge forums. Is it possible for someone to go in an update that news entry? Below is a quick link to the relevant post:
https://sourceforge.net/forum/forum.php?forum_id=981086
Best,
- Gerry
Bruno Postle
>
> So back to the original post, the link in the news section for the
> 0.8.0 release still points to the 0.7.0 release notes.
Thanks, fixed.
> I do not appear to have access to edit the entries in the
> sourceforge forums.
Fixed.
--
Bruno
Gerry Patterson
Bruno,
In an effort to continue to abuse this expired equine, the "Download Now!" button on the main sourceforge page for the project points to the 0.7.0 tar ball. I am thinking it should also be updated to point to 0.8.0 as well. I hunted around to see where to change it, but couldn't find it.
Best Regards,
- Gerry
Bruno Postle
>
>In an effort to continue to abuse this expired equine, the "Download Now!"
>button on the main sourceforge page for the project points to the 0.7.0 tar
>ball. I am thinking it should also be updated to point to 0.8.0 as well. I
>hunted around to see where to change it, but couldn't find it.
Ok, it was ok for OS X which pointed to the DMG, I've fixed it for
Linux to point to the tarball, but I have no idea what the Windows
default is. We need a 0.8.0 Windows installer on sourceforge.
--
Bruno
Yuval Levy
Allard is putting up the final touches to the 0.8.0 Windows installer.
where do you change the "Download Now!" link? I looked everywhere on SF
and did not find that...
Yuv
Bruno Postle
>
>where do you change the "Download Now!" link? I looked everywhere on SF
>and did not find that...
It has changed at some point, it is now at Project Admin -> File
Manager. Find the file, click on it and a previously invisible form
appears...
--
Bruno
Yuval Levy
thanks for the info. either I was having a senior moment when looking
for that, or this goes under the header of best practice intuitive user
interface... not!
Yuv