The problem to solve is the artist must be able to get her images easily online with zero computerish hassle to do it.
The Image Uploader step is looking strong. It knows valid Unix file names and it won't let the upload proceed. That was the last problem as it was previously too restrictive and now I'm sure if it's legal then it will go. One of the most obvious errors is using blanks in a file name as they are a huge nuisance in Unix. So, this one is closed.
There had been a concern for what does she do if a file is corrupted in the upload but that's covered with a Purge Uploads routine that lets her pick image files to be deleted from those that have been uploaded, perhaps more than one. That's satisfactorily tested and I have uploaded, purged, and re-uploaded the same images over and over to be sure. This routine will NOT delete anything out of the production Images folder.
The Image Mover doesn't need much validation. If the image file is really there than it will move it. I'll add a check to see if the file really exists but, if you pushed it, you could get a broken name into it so a validation step is worthwhile. It won't do any harm if the image file isn't there, the program just won't do anything.
The Image Updater has been tested quite a bit and I'm satisfied with the validation in it. There's one piece that still nags a bit. This will write an updated copy of the Art Information File but it rewrites it in-place. If her computer goes down then the file is smashed and can only be recovered from a backup. The probability of this is ridiculously small but systems programmers know everything single thing that can possibly break definitely will.
It's not a difficult step to add as the Image Updater can write to a new Art Information File. On successful completion of the write, it can swap out that one with the production version. If you're getting the system programmer vibe now you will be saying, well, that needs a way to toggle it back, doesn't it. And, yep, it does. Note: these things are not difficult, it's just important to anticipate them.
The things I tell you are very basic but many don't know them or ignore them.
Save that one piece about toggling the Art Information File, the flow of this thing is looking strong as in hard to break or to get into a situation from which you cannot extricate yourself. The thing that prevents me from opening the Admin section now is I'm considering what else it should do. It would be too confusing to use if things change after it is implemented.
Note: open is not the same as public. A maximum of three people will have permission to use the function.
I'm still not going to open it as the keyword is anticipate. What else would an artist realistically need to do to the site that wouldn't be better served by going into the filesystem yourself.
Note: a Store is coming. It's just waiting for product as there's no point in putting anything like that online until it's ready to do business. Ol' Dad has some ideas so I'm staying light on this so I'm just staying low until I know what they put together and then that will go into a Store on the site.
So, I put this out here so Artist and ol' Dad can see what develops.
Here are some examples.
Maybe the Artist wants to add a whole new page for a Gallery. She has done an exhibition somewhere and has some great pics so let's get this online. This was an especially important one so she wants to feature it specifically. So what do we do.
Much of what I do involves generating HTML dynamically as in the pages build themselves when you look at them but it's also possible to do permanent additions to HTML such as adding a new entry to the menu of site functions on the left. The process would be to create a gallery in some magical way and then create a link to it which is remembered permanently. This is possible but whether it has value is another question. I'm sure there is value to a consistent theme but this process would make it impossible to give any special styling to a new gallery. This would be a 'cookie cutter' approach and probably not artistically desirable.
One of the reasons it's fun to get stoned and play with computers is my latest thought is VGL (i.e. Valerie Gallery Language). Since we don't want a cookie-cutter gallery page, it has to be built in some custom way ... but ... without custom programming from a Web monster somewhere.
&gallery = Really Damn Cool Ann Arbor Show
&hookimage = ann-arbor-pano.jpg
&featureimage = aa-pic1.jpg, ... aa-picn.jpg
&relatedimage = aa-pic1-big.jpg, ... aa-picn-big.jpg
Those simple pieces of information would be enough to build the page in the same format as the home page which is a feature of the A1 show (I believe). That page has a large hook image and a number of smaller feature images so the above information would be enough to build a similar page and make it permanent.
If you want to get ludicrous with it, consider a page with a command line at the bottom and that page keeps executing itself recursively each time you enter a command so that way you can watch it build itself. I know I can do this or I wouldn't say it. I'm starting to think I want to do it because it would be cool to watch.
But ... does it have any value to the Artist.
Nevertheless, anticipate. What else might it do.
How about email list manager. It accumulates email addresses from people who want to get onto the mailing list and saves them up for you. Add ancillary functions for display, update, or transmitting, etc. It would not be difficult to use the site as the email broadcaster. Note: this isn't grandstanding as it's not difficult code. The only question is whether it's worthwhile doing it.
(Ed: if you can learn PHP in a few days, why can't you speak fluent German after almost two years?)
You tell me, bro. I wish to hell I knew!
How about The Artist Show. Don't think of video in terms of pulling it down from YouTube. What do you think it would take to transmit live video. I was thinking of possibly writing the code but it would be better to embed a window from Ustream or similar as it has servers powerful enough for repeating the video whereas a home system would be flogged. And the Comcast goons would come to kill your dog.
The laptap cam would be adequate for the video feed and this has some actual merit as it would offer the opportunity to present unfinished works should she wish to talk about them. Teaching probably isn't high on her list of things just now but doing something of this nature could put a different twist on it. The crass ol' Uncle suggests potentially making such a thing a subscription service.
Don't think Bob Ross and immediately dismiss this. The cat had one hell of a lot of fun doing what he did and a lot of people loved him. They probably still do as he was a young guy when I saw him on TV. Admittedly, so was I. Oh, and he probably made a bundle too as he sold a lot of how-to books on watercolors.
Think what is different about this Valerie Fraser site. What gives you a reason to go back after you have seen the images. You are motivated if you like them to find if there are new ones but what else can enhance that. The purpose of the Twitter window is to provide some of that in terms of near-real time information but what else.
The Image Uploader step is looking strong. It knows valid Unix file names and it won't let the upload proceed. That was the last problem as it was previously too restrictive and now I'm sure if it's legal then it will go. One of the most obvious errors is using blanks in a file name as they are a huge nuisance in Unix. So, this one is closed.
There had been a concern for what does she do if a file is corrupted in the upload but that's covered with a Purge Uploads routine that lets her pick image files to be deleted from those that have been uploaded, perhaps more than one. That's satisfactorily tested and I have uploaded, purged, and re-uploaded the same images over and over to be sure. This routine will NOT delete anything out of the production Images folder.
The Image Mover doesn't need much validation. If the image file is really there than it will move it. I'll add a check to see if the file really exists but, if you pushed it, you could get a broken name into it so a validation step is worthwhile. It won't do any harm if the image file isn't there, the program just won't do anything.
The Image Updater has been tested quite a bit and I'm satisfied with the validation in it. There's one piece that still nags a bit. This will write an updated copy of the Art Information File but it rewrites it in-place. If her computer goes down then the file is smashed and can only be recovered from a backup. The probability of this is ridiculously small but systems programmers know everything single thing that can possibly break definitely will.
It's not a difficult step to add as the Image Updater can write to a new Art Information File. On successful completion of the write, it can swap out that one with the production version. If you're getting the system programmer vibe now you will be saying, well, that needs a way to toggle it back, doesn't it. And, yep, it does. Note: these things are not difficult, it's just important to anticipate them.
The things I tell you are very basic but many don't know them or ignore them.
Save that one piece about toggling the Art Information File, the flow of this thing is looking strong as in hard to break or to get into a situation from which you cannot extricate yourself. The thing that prevents me from opening the Admin section now is I'm considering what else it should do. It would be too confusing to use if things change after it is implemented.
Note: open is not the same as public. A maximum of three people will have permission to use the function.
I'm still not going to open it as the keyword is anticipate. What else would an artist realistically need to do to the site that wouldn't be better served by going into the filesystem yourself.
Note: a Store is coming. It's just waiting for product as there's no point in putting anything like that online until it's ready to do business. Ol' Dad has some ideas so I'm staying light on this so I'm just staying low until I know what they put together and then that will go into a Store on the site.
So, I put this out here so Artist and ol' Dad can see what develops.
Here are some examples.
Maybe the Artist wants to add a whole new page for a Gallery. She has done an exhibition somewhere and has some great pics so let's get this online. This was an especially important one so she wants to feature it specifically. So what do we do.
Much of what I do involves generating HTML dynamically as in the pages build themselves when you look at them but it's also possible to do permanent additions to HTML such as adding a new entry to the menu of site functions on the left. The process would be to create a gallery in some magical way and then create a link to it which is remembered permanently. This is possible but whether it has value is another question. I'm sure there is value to a consistent theme but this process would make it impossible to give any special styling to a new gallery. This would be a 'cookie cutter' approach and probably not artistically desirable.
One of the reasons it's fun to get stoned and play with computers is my latest thought is VGL (i.e. Valerie Gallery Language). Since we don't want a cookie-cutter gallery page, it has to be built in some custom way ... but ... without custom programming from a Web monster somewhere.
&gallery = Really Damn Cool Ann Arbor Show
&hookimage = ann-arbor-pano.jpg
&featureimage = aa-pic1.jpg, ... aa-picn.jpg
&relatedimage = aa-pic1-big.jpg, ... aa-picn-big.jpg
If you want to get ludicrous with it, consider a page with a command line at the bottom and that page keeps executing itself recursively each time you enter a command so that way you can watch it build itself. I know I can do this or I wouldn't say it. I'm starting to think I want to do it because it would be cool to watch.
But ... does it have any value to the Artist.
Nevertheless, anticipate. What else might it do.
How about email list manager. It accumulates email addresses from people who want to get onto the mailing list and saves them up for you. Add ancillary functions for display, update, or transmitting, etc. It would not be difficult to use the site as the email broadcaster. Note: this isn't grandstanding as it's not difficult code. The only question is whether it's worthwhile doing it.
(Ed: if you can learn PHP in a few days, why can't you speak fluent German after almost two years?)
You tell me, bro. I wish to hell I knew!
How about The Artist Show. Don't think of video in terms of pulling it down from YouTube. What do you think it would take to transmit live video. I was thinking of possibly writing the code but it would be better to embed a window from Ustream or similar as it has servers powerful enough for repeating the video whereas a home system would be flogged. And the Comcast goons would come to kill your dog.
The laptap cam would be adequate for the video feed and this has some actual merit as it would offer the opportunity to present unfinished works should she wish to talk about them. Teaching probably isn't high on her list of things just now but doing something of this nature could put a different twist on it. The crass ol' Uncle suggests potentially making such a thing a subscription service.
Don't think Bob Ross and immediately dismiss this. The cat had one hell of a lot of fun doing what he did and a lot of people loved him. They probably still do as he was a young guy when I saw him on TV. Admittedly, so was I. Oh, and he probably made a bundle too as he sold a lot of how-to books on watercolors.
Think what is different about this Valerie Fraser site. What gives you a reason to go back after you have seen the images. You are motivated if you like them to find if there are new ones but what else can enhance that. The purpose of the Twitter window is to provide some of that in terms of near-real time information but what else.
No comments:
Post a Comment