Scratch

I'm trying to work out what attributes different elements will need. Here's a start:

Background:
Canvas height
Canvas width
Background image/colour
.                         colour/gradient

Link:
link type:
no link
link
random link
.          link 1
.          link 2
.          etc
.          add link

Image
fit to size?:
.           height
.           width
Image URL
Image position
.           x pos
.           y pos

text
string
position
.          xpos
.          ypos
font-colour
font size

Okay, already I'm wondering how we want to deal with online/offline control.

Last edited by sparks (2012-06-19 12:03:37)

sparks, if you don't mind, I'll post the list and you can edit it.

Background:
Canvas height
Canvas width
Background image/colour
.                         colour/gradient

Link:
link type:
no link
link
random link
.          link 1
.          link 2
.          etc
.          add link

Image
fit to size?:
.           height
.           width
Image URL
Image position
.           x pos
.           y pos

Text
string
position
.          xpos
.          ypos
font-colour
font size

Dynamic Text
Type: (list of pullable info)
User: The target user for the info (set to that user by default).
position
.        xpos
.        ypos
font-color
font-size
cut text if it exceeds [n] characters?

Dynamic Image
Type: (list of pullable info)
User: The target user for the info (set to that user by default).
position
.        xpos
.        ypos
Image URL
Resize?
.        width
.        height

Last edited by sparks (2012-06-19 13:00:58)

sparks wrote:

Perhaps clicking the GUI elements should still switch the properties window to them, and just have the elements list as a collapsed box that can be used in emergencies when the user can't reach the one they want to.

OK, I think that's definitely better.
Are we going to name the elements using <prefix><number>?

sparks wrote:

I think we should draw up a list of the data we want to be able to pull from the site too. Should Dynamic Text elements be allowed to have custom text in it too, or should the user have to put normal Text elements to either side?

I think dynamic text should allow custom input only if it covers the whole text, being too difficult to implement otherwise. For example, one could specify text for online/offline sensor:

When online, display text "I'm here and ready to help!"
When offline, display text "I'm not online yet"
or something.

Last edited by LS97 (2012-06-19 12:30:42)

sparks wrote:

Oh I see.

Mockup time!



A little "T" icon by text, with the first few letters of the text as a name, a small icon of the image and an image icon by dynamic ones.

Possibly the icons should be a little larger than 10x10

I like those little icons. For text, have
"Text <check out my...>"
instead, maybe?

Ooh, this API thingy should also have utillities for forum manipulation, like a rainbow text generator or a click to enlarge image generator.

Not plugins, just BB generators. All centralized in the API for easier usage.

The design looks really nice! I'd like to scratchify it a bit more by adding orange to the colour scheme and using the Scratch font for the logo.

I'm probably just as good as you at actually designing the website layout (I've done lots of it in the past), but I'm little to no good at making the graphics, so you go ahead  .

Last edited by LS97 (2012-06-19 14:41:05)

So. There are about four stages to this the way I see it.

Firstly you reach the site. At this point the user should probably log in. Are we going with logins? It might be simpler to let people create their own accounts, though Scratch linking would have its benifits.

Once they have logged in they can either create a new image, or edit an image they have created already.

The next stage would be the creation/editing of the image. This will probably be the bit with the most work needed 

Finally the user should choose whether their design is public or private, then click save and the image should be generated with a link to the image and a link for the link.

How are we transitioning between each stage? We could take the javascript route and have it all on one page, expanding and collapsing boxes as the user progresses through the stages, the HTML route with one section per page or some other way entirely. Thoughts?

Do you have any name ideas?

LS97 wrote:

I think you pretty much figured it out. We should begin by developing the features around the GUI editor first, and then move onto the core itself.

I'm not sure what you mean by "features around the GUI editor" there...

Oh of course! I suppose we've more or less covered the planning for the GUI now anyway, so discussing the actual system is a good next step. Certainly I'm expecting us to store the info for each image as a database value so maybe it would be worth working out how we're gonna do that. If we have unlimited or even just a high max of elements, I don't think a column for each element is going to work too well. I can think of three ways to do it off the top of my head.

We could store the entire image info for all elements in a single table using characters and numbers to represent settings, then decoding the value again to reconstruct the image. I worry this would be rather slow.

We could have a column for each element in the image, with all their properties stored as coded values that can be decoded upon building, again this may be slow.

Finally, and I think this might be the way to do it, is to have a row per element and a column for each property. an ID column can link all the elements of an image together, then we can do a "SELECT * FROM `database` WHERE 'ID'='$imageID'" to get all the elements back for the build. This would take up more database space, but might be faster for building.

I imagine layering elements is going to be a big problem. We'll have to make sure their z-index can be read back upon build, then draw the elements out from lowest to highest.

Last edited by sparks (2012-06-20 11:40:27)

So, the database stores elements in rows, and the properties of the elements in columns. I've amended your post above to start off a list of element properties.