squeak.org - an update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

squeak.org - an update

Chris Cunnington
I've redesigned squeak.org and I think all the problems are solved. The
problems were a doubling menu bar; an extraneous navbar; Altitude
components that didn't jibe with the Bootstrap layout; and, 24-char
tokens instead of regular looking URIs (i.e. /community or /blogs).

The way the Altitude's examples are laid out uses composition and a
class that acts as a frame with a navbar. The frame allows other
classes/components to be swapped out of an ivar called #current with the
navbar.

I did away with that and replaced composition with inheritance. Now
there is an abstract superclass (i.e. SQAbstractSuperclass) and every
page with content is a subclass with a #renderConentOn: method. The
navbar supplied by Bootstrap is created by the abstract superclass. All
links are hyperlinks (i.e. all "html a href:" and no "html a navigate:",
"html a callback:", or "html a linkTo:").

So the superclass creates the menu. All the content classes have
#renderContentOn:. The only remaining thing is to list all the tokens
you'll use for URIs in SQSqueakApplication>>#initializeLocator.

initializeLocator
     locator
         at: ALPath root
         put: SQHomePage new asResource.
     locator at: ALPath / 'license'
         put: SQLicensePage new asResource.
     locator at: ALPath / 'blogs'
         put: SQBlogsPage new asResource.
     locator at: ALPath / 'docs'
         put: SQDocumentationPage new asResource.
     locator at: ALPath / 'community'
         put: SQMailingListsPage new asResource.
     locator at: ALPath / 'devlinks'
         put: SQDeveloperLinksPage new asResource.
     locator at: ALPath / 'projects'
         put: SQProjectLinksPage new asResource.

The result is a website using standard looking URIs that is dead easy to
make. It won't win any prizes, but it fits the spec and is simple as a
pin. Altitude is nothing of not versatile. There are color, positioning,
etc. details so it'll be a few days before I deploy the new version.

Chris

Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

Bert Freudenberg

On 2012-12-18, at 21:32, Chris Cunnington <[hidden email]> wrote:

I've redesigned squeak.org and I think all the problems are solved. The problems were a doubling menu bar; an extraneous navbar; Altitude components that didn't jibe with the Bootstrap layout; and, 24-char tokens instead of regular looking URIs (i.e. /community or /blogs).

The way the Altitude's examples are laid out uses composition and a class that acts as a frame with a navbar. The frame allows other classes/components to be swapped out of an ivar called #current with the navbar.

I did away with that and replaced composition with inheritance. Now there is an abstract superclass (i.e. SQAbstractSuperclass) and every page with content is a subclass with a #renderConentOn: method. The navbar supplied by Bootstrap is created by the abstract superclass. All links are hyperlinks (i.e. all "html a href:" and no "html a navigate:", "html a callback:", or "html a linkTo:").

So the superclass creates the menu. All the content classes have #renderContentOn:. The only remaining thing is to list all the tokens you'll use for URIs in SQSqueakApplication>>#initializeLocator.

initializeLocator
   locator
       at: ALPath root
       put: SQHomePage new asResource.
   locator at: ALPath / 'license'
       put: SQLicensePage new asResource.
   locator at: ALPath / 'blogs'
       put: SQBlogsPage new asResource.
   locator at: ALPath / 'docs'
       put: SQDocumentationPage new asResource.
   locator at: ALPath / 'community'
       put: SQMailingListsPage new asResource.
   locator at: ALPath / 'devlinks'
       put: SQDeveloperLinksPage new asResource.
   locator at: ALPath / 'projects'
       put: SQProjectLinksPage new asResource.

The result is a website using standard looking URIs that is dead easy to make. It won't win any prizes, but it fits the spec and is simple as a pin. Altitude is nothing of not versatile. There are color, positioning, etc. details so it'll be a few days before I deploy the new version.

Chris

Sounds good. In addition:

IMHO we should try to match the existing URLs unless the new structure is too different in places.

This would mean e.g. the community page should live at /Community not /community, documentation at /Documentation not /docs etc. External deep links would continue to work, which I generally consider a Good Thing.

Alternatively, we could add redirects from the old locations to their new home.

And it would be a good idea to monitor the error log to find out about old URLs in use. Altitude does create access logs and error logs, I assume? Or would that be handled by Apache?

Also, the error page should be customized, currently it is not too helpful:


If it instead displayed a site map (list of all major pages), people arriving from dead URLs could still quickly jump to where they would want to go. Also, it would be cool to have a nice graphic, e.g.:
                             
(if you want to use that, we need to give attribution to AMENAZAGFX, because I based it on http://www.officialpsds.com/Hole-in-Paper-3-PSD50497.html)

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

Chris Cunnington
On 2012-12-19 5:49 AM, Bert Freudenberg wrote:

On 2012-12-18, at 21:32, Chris Cunnington <[hidden email]> wrote:

I've redesigned squeak.org and I think all the problems are solved. The problems were a doubling menu bar; an extraneous navbar; Altitude components that didn't jibe with the Bootstrap layout; and, 24-char tokens instead of regular looking URIs (i.e. /community or /blogs).

The way the Altitude's examples are laid out uses composition and a class that acts as a frame with a navbar. The frame allows other classes/components to be swapped out of an ivar called #current with the navbar.

I did away with that and replaced composition with inheritance. Now there is an abstract superclass (i.e. SQAbstractSuperclass) and every page with content is a subclass with a #renderConentOn: method. The navbar supplied by Bootstrap is created by the abstract superclass. All links are hyperlinks (i.e. all "html a href:" and no "html a navigate:", "html a callback:", or "html a linkTo:").

So the superclass creates the menu. All the content classes have #renderContentOn:. The only remaining thing is to list all the tokens you'll use for URIs in SQSqueakApplication>>#initializeLocator.

initializeLocator
   locator
       at: ALPath root
       put: SQHomePage new asResource.
   locator at: ALPath / 'license'
       put: SQLicensePage new asResource.
   locator at: ALPath / 'blogs'
       put: SQBlogsPage new asResource.
   locator at: ALPath / 'docs'
       put: SQDocumentationPage new asResource.
   locator at: ALPath / 'community'
       put: SQMailingListsPage new asResource.
   locator at: ALPath / 'devlinks'
       put: SQDeveloperLinksPage new asResource.
   locator at: ALPath / 'projects'
       put: SQProjectLinksPage new asResource.

The result is a website using standard looking URIs that is dead easy to make. It won't win any prizes, but it fits the spec and is simple as a pin. Altitude is nothing of not versatile. There are color, positioning, etc. details so it'll be a few days before I deploy the new version.

Chris

Sounds good. In addition:

IMHO we should try to match the existing URLs unless the new structure is too different in places.

This would mean e.g. the community page should live at /Community not /community, documentation at /Documentation not /docs etc. External deep links would continue to work, which I generally consider a Good Thing.

Alternatively, we could add redirects from the old locations to their new home.

And it would be a good idea to monitor the error log to find out about old URLs in use. Altitude does create access logs and error logs, I assume? Or would that be handled by Apache?

Also, the error page should be customized, currently it is not too helpful:


If it instead displayed a site map (list of all major pages), people arriving from dead URLs could still quickly jump to where they would want to go. Also, it would be cool to have a nice graphic, e.g.:
                             
(if you want to use that, we need to give attribution to AMENAZAGFX, because I based it on http://www.officialpsds.com/Hole-in-Paper-3-PSD50497.html)

- Bert -




    
Those are all good ideas. And I think they'll round out the user experience in important ways. Added to which they're simple to do. The only thing is that I think they're a bit ahead of the curve. These ideas to me are closer to actual deployment. I'm going to complete the basic site and then I'll add these things. I like the picture for an error message.

Chris


Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

Frank Shearar-3
On 19 December 2012 13:46, Chris Cunnington <[hidden email]> wrote:
On 2012-12-19 5:49 AM, Bert Freudenberg wrote:

On 2012-12-18, at 21:32, Chris Cunnington <[hidden email]> wrote:

I've redesigned squeak.org and I think all the problems are solved. The problems were a doubling menu bar; an extraneous navbar; Altitude components that didn't jibe with the Bootstrap layout; and, 24-char tokens instead of regular looking URIs (i.e. /community or /blogs).

The way the Altitude's examples are laid out uses composition and a class that acts as a frame with a navbar. The frame allows other classes/components to be swapped out of an ivar called #current with the navbar.

I did away with that and replaced composition with inheritance. Now there is an abstract superclass (i.e. SQAbstractSuperclass) and every page with content is a subclass with a #renderConentOn: method. The navbar supplied by Bootstrap is created by the abstract superclass. All links are hyperlinks (i.e. all "html a href:" and no "html a navigate:", "html a callback:", or "html a linkTo:").

So the superclass creates the menu. All the content classes have #renderContentOn:. The only remaining thing is to list all the tokens you'll use for URIs in SQSqueakApplication>>#initializeLocator.

initializeLocator
   locator
       at: ALPath root
       put: SQHomePage new asResource.
   locator at: ALPath / 'license'
       put: SQLicensePage new asResource.
   locator at: ALPath / 'blogs'
       put: SQBlogsPage new asResource.
   locator at: ALPath / 'docs'
       put: SQDocumentationPage new asResource.
   locator at: ALPath / 'community'
       put: SQMailingListsPage new asResource.
   locator at: ALPath / 'devlinks'
       put: SQDeveloperLinksPage new asResource.
   locator at: ALPath / 'projects'
       put: SQProjectLinksPage new asResource.

The result is a website using standard looking URIs that is dead easy to make. It won't win any prizes, but it fits the spec and is simple as a pin. Altitude is nothing of not versatile. There are color, positioning, etc. details so it'll be a few days before I deploy the new version.

Chris

Sounds good. In addition:

IMHO we should try to match the existing URLs unless the new structure is too different in places.

This would mean e.g. the community page should live at /Community not /community, documentation at /Documentation not /docs etc. External deep links would continue to work, which I generally consider a Good Thing.

Alternatively, we could add redirects from the old locations to their new home.

And it would be a good idea to monitor the error log to find out about old URLs in use. Altitude does create access logs and error logs, I assume? Or would that be handled by Apache?

Also, the error page should be customized, currently it is not too helpful:


If it instead displayed a site map (list of all major pages), people arriving from dead URLs could still quickly jump to where they would want to go. Also, it would be cool to have a nice graphic, e.g.:
                             
(if you want to use that, we need to give attribution to AMENAZAGFX, because I based it on http://www.officialpsds.com/Hole-in-Paper-3-PSD50497.html)

- Bert -




    
Those are all good ideas. And I think they'll round out the user experience in important ways. Added to which they're simple to do. The only thing is that I think they're a bit ahead of the curve. These ideas to me are closer to actual deployment. I'm going to complete the basic site and then I'll add these things. I like the picture for an error message.

Especially when it points to a topic of active discussion, NetNameResolver :)

frank 
 
Chris






cbc
Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

cbc
In reply to this post by Bert Freudenberg
I like the image that Bert sent below.  Is there anything in Squeak that does something like this?  Or, better yet (for me), that would make it look like he image was torn out of a page - frayed, uneven edges that indicate the image is not a complete picture, but just part of one?

Thanks,
Chris


On Wed, Dec 19, 2012 at 2:49 AM, Bert Freudenberg <[hidden email]> wrote:

On 2012-12-18, at 21:32, Chris Cunnington <[hidden email]> wrote:

I've redesigned squeak.org and I think all the problems are solved. The problems were a doubling menu bar; an extraneous navbar; Altitude components that didn't jibe with the Bootstrap layout; and, 24-char tokens instead of regular looking URIs (i.e. /community or /blogs).

The way the Altitude's examples are laid out uses composition and a class that acts as a frame with a navbar. The frame allows other classes/components to be swapped out of an ivar called #current with the navbar.

I did away with that and replaced composition with inheritance. Now there is an abstract superclass (i.e. SQAbstractSuperclass) and every page with content is a subclass with a #renderConentOn: method. The navbar supplied by Bootstrap is created by the abstract superclass. All links are hyperlinks (i.e. all "html a href:" and no "html a navigate:", "html a callback:", or "html a linkTo:").

So the superclass creates the menu. All the content classes have #renderContentOn:. The only remaining thing is to list all the tokens you'll use for URIs in SQSqueakApplication>>#initializeLocator.

initializeLocator
   locator
       at: ALPath root
       put: SQHomePage new asResource.
   locator at: ALPath / 'license'
       put: SQLicensePage new asResource.
   locator at: ALPath / 'blogs'
       put: SQBlogsPage new asResource.
   locator at: ALPath / 'docs'
       put: SQDocumentationPage new asResource.
   locator at: ALPath / 'community'
       put: SQMailingListsPage new asResource.
   locator at: ALPath / 'devlinks'
       put: SQDeveloperLinksPage new asResource.
   locator at: ALPath / 'projects'
       put: SQProjectLinksPage new asResource.

The result is a website using standard looking URIs that is dead easy to make. It won't win any prizes, but it fits the spec and is simple as a pin. Altitude is nothing of not versatile. There are color, positioning, etc. details so it'll be a few days before I deploy the new version.

Chris

Sounds good. In addition:

IMHO we should try to match the existing URLs unless the new structure is too different in places.

This would mean e.g. the community page should live at /Community not /community, documentation at /Documentation not /docs etc. External deep links would continue to work, which I generally consider a Good Thing.

Alternatively, we could add redirects from the old locations to their new home.

And it would be a good idea to monitor the error log to find out about old URLs in use. Altitude does create access logs and error logs, I assume? Or would that be handled by Apache?

Also, the error page should be customized, currently it is not too helpful:


If it instead displayed a site map (list of all major pages), people arriving from dead URLs could still quickly jump to where they would want to go. Also, it would be cool to have a nice graphic, e.g.:
                             
(if you want to use that, we need to give attribution to AMENAZAGFX, because I based it on http://www.officialpsds.com/Hole-in-Paper-3-PSD50497.html)

- Bert -







Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

Bert Freudenberg
On 2013-03-12, at 00:18, Chris Cunningham <[hidden email]> wrote:

I like the image that Bert sent below.  Is there anything in Squeak that does something like this?  Or, better yet (for me), that would make it look like he image was torn out of a page - frayed, uneven edges that indicate the image is not a complete picture, but just part of one?

Just paint a suitable mask using your tool of choice. Then:

mask := PNGReadWriter formFromFileNamed: 'mask.png'.
image := Display copy: mask boundingBox.
mask displayOn: image at: 0@0 rule: Form blend.
image asMorph openInHand.

Feel free to use the mask I attached (but you have to bow once to my mad artistic skills). It might be invisible in your email client though, unless it does display the gray background I tried to set.

- Bert - 

   


Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

Bert Freudenberg
On 2013-03-12, at 12:20, Bert Freudenberg <[hidden email]> wrote:

> mask := PNGReadWriter formFromFileNamed: 'mask.png'.
> image := Display copy: mask boundingBox.
> mask displayOn: image at: 0@0 rule: Form blend.
> image asMorph openInHand.

Hehe, this is fun. A couple more lines and you have a real fuzzy screenshot tool:

mask := PNGReadWriter formFromFileNamed: 'mask.png'.
image := Form fromUser.
scaledMask := Form extent: image extent depth: 32.
mask displayScaledOn: scaledMask.
scaledMask displayOn: image at: 0@0 rule: Form blend.
fileName := FileDirectory default nextNameFor: 'screenshot' extension: 'png'.
image asMorph name: fileName; openCenteredInWorld.
Cursor write showWhile: [PNGReadWriter putForm: image onFileNamed: fileName].

- Bert -


cbc
Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

cbc
Very nice!  almost exactly what I wanted (need to tweak the mask - a little too agressive for my tasted).

Also, to write the form out, you could use:

image writePNGfileNamed:'screenshot.png'.

(or are you/we trying to move away from including '.' in filenames?)

one final thing - your previous email, I couldn't see any text, or most of the rest of the message, in GMail.  First time that I'm aware of that. Had to look at source to see what you wrote. Odd.

-Chris


On Tue, Mar 12, 2013 at 5:48 AM, Bert Freudenberg <[hidden email]> wrote:
On 2013-03-12, at 12:20, Bert Freudenberg <[hidden email]> wrote:

> mask := PNGReadWriter formFromFileNamed: 'mask.png'.
> image := Display copy: mask boundingBox.
> mask displayOn: image at: 0@0 rule: Form blend.
> image asMorph openInHand.

Hehe, this is fun. A couple more lines and you have a real fuzzy screenshot tool:

mask := PNGReadWriter formFromFileNamed: 'mask.png'.
image := Form fromUser.
scaledMask := Form extent: image extent depth: 32.
mask displayScaledOn: scaledMask.
scaledMask displayOn: image at: 0@0 rule: Form blend.
fileName := FileDirectory default nextNameFor: 'screenshot' extension: 'png'.
image asMorph name: fileName; openCenteredInWorld.
Cursor write showWhile: [PNGReadWriter putForm: image onFileNamed: fileName].

- Bert -





Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

Bert Freudenberg

On 2013-03-12, at 16:48, Chris Cunningham <[hidden email]> wrote:

Very nice!  almost exactly what I wanted (need to tweak the mask - a little too agressive for my tasted).

Also, to write the form out, you could use:

image writePNGfileNamed:'screenshot.png'.

Hmm, writePNGfileNamed: is not in my image.

(or are you/we trying to move away from including '.' in filenames?)

Huh? My method automatically numbers each screenshot: screenshot.1.png, screenshot.2.png, etc.

one final thing - your previous email, I couldn't see any text, or most of the rest of the message, in GMail.  First time that I'm aware of that. Had to look at source to see what you wrote. Odd.

-Chris


It was white text on gray background. Just an experiment. Failed, obviously.

- Bert -



On Tue, Mar 12, 2013 at 5:48 AM, Bert Freudenberg <[hidden email]> wrote:
On 2013-03-12, at 12:20, Bert Freudenberg <[hidden email]> wrote:

> mask := PNGReadWriter formFromFileNamed: 'mask.png'.
> image := Display copy: mask boundingBox.
> mask displayOn: image at: 0@0 rule: Form blend.
> image asMorph openInHand.

Hehe, this is fun. A couple more lines and you have a real fuzzy screenshot tool:

mask := PNGReadWriter formFromFileNamed: 'mask.png'.
image := Form fromUser.
scaledMask := Form extent: image extent depth: 32.
mask displayScaledOn: scaledMask.
scaledMask displayOn: image at: 0@0 rule: Form blend.
fileName := FileDirectory default nextNameFor: 'screenshot' extension: 'png'.
image asMorph name: fileName; openCenteredInWorld.
Cursor write showWhile: [PNGReadWriter putForm: image onFileNamed: fileName].

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

Stéphane Rollandin
> It was white text on gray background. Just an experiment. Failed, obviously.
>
> - Bert -

Worked for me (Thunderbird client).

Stef


cbc
Reply | Threaded
Open this post in threaded view
|

Re: squeak.org - an update

cbc
In reply to this post by Bert Freudenberg
Hmm.  Well, yesterday wasn't my day.

On Tue, Mar 12, 2013 at 9:17 AM, Bert Freudenberg <[hidden email]> wrote:

On 2013-03-12, at 16:48, Chris Cunningham <[hidden email]> wrote:

image writePNGfileNamed:'screenshot.png'.

Hmm, writePNGfileNamed: is not in my image.

That's because I added it to my image on the 11th.  And the forgot that I had done that.
I've added  "Graphics-cbc.203"  to the inbox with this method.
(or are you/we trying to move away from including '.' in filenames?)

Huh? My method automatically numbers each screenshot: screenshot.1.png, screenshot.2.png, etc.

Right.  I see that now - but completely missed the method you used.  Neat method - I'll start using it elsewhere. 

It was white text on gray background. Just an experiment. Failed, obviously.

Just for me.

I'm enjoying using this so far...

-Chris