...more recent posts
I made the change this week from NetNewsWire (backed by Google Reader for syncing) to the web based Feedly for RSS reading. It's always a little hard to change, but Feedly is good and I'm already pretty used to it. Google Reader closes down on Monday, so if you use an RSS reader that stores your info in Google Reader (many do) you need to change to something else soon. Feedly will import all your subscriptions from Google automatically.
Down to the wire before vacation, but I'm really happy with the progress I've made in the last couple of weeks on Geneva. Still lacking some templates (there is only one currently) but otherwise it is set to demo. I just need to update the new site database to match the dev database and then people can start rolling out sites and playing around.
Fixed an issue where the creation of a new site would fail if there was an upper case character in the site name (!).
Also, I can see that a bunch of people have tried this out and pretty much no one has gotten anywhere (even where the above bug was not encountered.) I think I understand some of the problems people are probably running into. It's not completely clear what to do (to put it mildly) once you make a site. The front page exists, but there is no content on it. I made some changes today which address a good part of these issues, but I still have a few more ideas to implement. So if you gave up wait for my next update and please try again - it will be a lot more straightforward soon.
Okay, I've got all of the CSS visual editor issues cleared up. I've also made a way to make subdomains here at digitalmediatree (rather than gevenvawebsites.com). This is one of my long range plans for the software - that I can put the ability to make sites behind any domain. So my clients will be end users who want their own sites, but hopefully also people like me that also have clients who want to build their own sites.
Anyway, the point here is that you can make a something.digitalmediatree.com site right now to check out what I am doing. Use this link:
http://genevawebsites.com/createsite/?dmt=true
This should create the site and land you on yoursite.digitalmediatree.com/geneva-first-run/ where you will be asked to make a username and password, and optionally leave an email address if you want to be able to recover your password. Once you pick a username and password you will be automatically logged in and taken to yoursite.digitalmediatree.com/help/ which has very brief overview of how to accomplish certain basic tasks.
To start the front page has been created, but there is nothing there. As with all geneva pages you can go to the front page and double click to get the edit palette. The front page has one container, called 'minimal main'. You can choose that from the edit palatte and click 'define container' since the container exists but the system needs to be told what kind of container you want. If you want to play around select 'textara' for 'container function:' and then give it any name right below where it says 'new name:'. Leave the rest of the options alone and click 'Save Changes'.
This will take you back to the front page. Double click anywhere again to get the edit palette, and now when you click on 'minimal main' it will say 'edit contents' instead of 'define container'. Click 'edit contents' to get to the usual posting box for entering text into your container. Enter some text and click 'Save'. You will be taken back to the front page where your text should be visible. Now dobule click to get the edit palette again, click on 'minimal main', and now you can start playing around with the visual CSS editor. The editor opens initially to 'typography', but you can use that pull down to access the other areas: margins, padding, border, and colors. Click 'Save' at the bottom of the palette to save your changes and return to the page.
The main new thing about the edit palette is now every CSS option has a checkbox next to it labeled 'inherit'. If 'inherit' is checked it means that the CSS style in question has no value, and thus "inherits" it's value from it's parent element. This is how CSS works, it "cascades" down in specificity (CSS stands for Cascading Style Sheets.) This is all beyond the scope of this post, but you can think of the inherit checkbox as a switch to turn off that style (or maybe think of it as 'return to default'.) If you uncheck 'inherit' you will reveal the control for that style which will let you change it (font-size, color, etc...). If you ever want to remove something you've done, just set the control to 'inherit' and your changes will be removed.
Still too early to really do very much, but this much is definitely working and I'd love if anyone played around with it. As always let me know if you run into any trouble...
I've temporarily given non logged in users the ability to edit over at genevawebsites so that you could check out what I'm up to if you wish. Go to http://genevawebsites.com/test/ and there is some text that (hopefully) explains a little about what is possible. I'm pretty sure only a few people read this page, so I'm hoping leaving it open for a bit will be okay.
On a related note, I'm less happy with genevawebsites.com as a name now. Was hoping to maybe get genevaweb.com or gvaweb.com instead (gva is the geneva airport code) but of course they are taken. gvaspot.com is available, but I think too derivative of blogspot. gvasites.com is available but I'm not quite feeling that. It's really hard to pick a short name that's not already taken. I would even abandon geneva altogether if I could think of something better, although I think it has a nice ring to it. Anyway, if anyone has any suggestions I am all ears.
So I've run into an issue with geneva. It's not a programming problem, it's conceptual. This is sure to be boring, but I'll just write it out in the hopes of making it more clear to myslef.
You build pages in geneva by selecting templates. Templates are basically HTML files. You can either use a pre built template, or use the browser based HTML editor to make your own. The only difference between a geneva template and a regular HTML file is that templates can contain "containers" which hold editable parts of the page. You insert containers into a template by like this: {{container name}}, where "container name" is any name you choose. Then you define your container on another admin page. Containers can be "textareas" (which gives you an editable piece of text), "snippets" (which are like textareas, but specifically for HTML, CSS, or Javascript code,) "blogs", "images", and eventually things like "photo galleries", "sign up forms", and any other type of component I make.
So far so good. One of the powerful things about containers is reusability. Once you define a container you can insert it into any page. So, image you have an image for your site logo. You create a container called, say, "logo", define that container as an image component, and upload your image. Now you can just put {{logo}} into any page you create and this will be rendered as your uploaded logo image. If you then edit the logo container and change the image it will be updated on all pages of the site.
The problem I am having has to do with naming the containers. I want to have a central repository of pre built templates. These templates will of course include containers since this is the whole point of geneva - making pages which are editable by the site admins. But since you choose your own names for containers, this might lead to problems. A template might specify a container called "main" which holds the main content of a page (say a textarea with a bio for an /about-us/ page.) But you might have already used the name "main" for a different type of container. If so, when you choose the prebuilt template with container "main", instead of getting the intended textarea, you might get a blog, or an image gallery, or whatever component you have previously assigned to the "main" container.
The typical solution here is something like name spacing. I could prefix every container name with the template name. So if you choose a template called, say, "minimal two column", and it contains a container "main", that container would actually have the full name something like "minimal two column : main". Now there can't be any collisions between similarly named containers in different templates. Problem solved.
Except no, because although that would be useful in some situations (where you don't want collisions) it defeats another of the powers of containers: reusability. Sometimes you want the same container to work across multiple templates. Take our original logo container as an example. In this case you want the container "logo" to be the same no matter which template a page is using so that future updates to the contents of "logo" (i.e., you upload a new image when your logo changes) update all pages.
So how do I make it so that I can build new templates with containers that can be used by anybody with a geneva web site, without knowing ahead of time whether a particular geneva web site already has a container specified with that name?
I think the solution is in this direction: templates specify empty containers. Like: {{ }}. Then when you choose a template to use you have to name the containers. But I don't like the extra step this involves. I'd like a site builder to just be able to drop in new templates and have them immediately work. I don't think there is a way around this issue.
Maybe (now I'm just thinking out loud here which I guess is the point) templates can specify containers differently. Something like {{{ }}} and inside have not a container name, but the suggested component. So the template would initally have containers like {{{image}}}, or {{{textarea}}} or {{{blog}}}. And when you choose a template for a page, and then view that page for the first time, you see each container with a default version of that component (a default geneva logo for {{{image}}} containers, lorum ipsum text for {{{textarea}}}, etc...). Then you just edit the page as normal (which is super easy and I'm really excited about this part, but that's another story...) and replace the default content with your own.
Hmmm. Would that work?
I've been working on geneva non stop. The delay is because I decided to include a feature that was going to wait for the 2.0 release. It's a visual CSS editor. I'm not the first (or hundreth) person to build one, but it is not an easy thing to do. So it's taking longer than expected. Still, it's taking perhaps less time than I thought it might, so that's good. I don't have controls for every CSS selector I want to include, but I have a good start. Certainly I'm passed the proof of concept stage and as a result I don't anticipate running into any show stopping bugs. Perhaps I'll find that it doesn't work in older versions of IE, but this is only on admin pages and I don't mind excluding those versions of IE from being usable on the admin side.
Still have to make a few basic templates. Then get a fresh copy of the database ready. And then I'll be ready for some outside testing to begin. Not sure if I'll get a full day of work tomorrow, but if so I might be ready.
I am jumping the gun here, but today is my deadline, so I'm just going to do it. I've "launched" a new site: genevawebsites.com.
This is the culmination of many years work. There is still a lot more to do, but at a very basic level it is functional and so I want to start getting feedback as soon as possible.
I have a blog on the new site where I will post about the site as it matures: genevawebsites.com/blog/
And you can use it to build a website of your own by going to: genevawebsites.com/createsite/
There probably isn't enough documentation yet for you to get very far, but you never know. New sites created will initially exist at something.genevawebsites.com where "something" is a name you supply on the /checkitout/ page. You build your site at that URI, and then if someone decides to stick with it they can supply a "real" URI ("whateveryouwant.com") which I can map to your something.genevawebsites.com subdomain.
I'll have a lot more to say in the coming days, but I wanted to give myself a little birthday present by launching at least something today. Have fun.
The image upload function (only from the new [post] page, not from [image upload] which is deprecated) now tries to deal with image orientation. As far as I know this is only an issue with the iPhone (and I think maybe only with older iPhones.) The problem is that when you take a portrait style (as opposed to landscape style) image the iPhone adds some exif data to the image file noting that it is rotated, but it doesn't actually rotate the image. When viewing the image some display programs know to look for the orientation data and rotate the image, but most do not (like, for instance, Apple's own Safari browser - wtf Apple?) So when you upload an image like this it will display as landscape even though it should be rotated 90 degrees. The upload script here now looks for the exif orientation data, and if present it actually rotates the image for you.
I'm only mentioning this so that people will speak up if this screws up and rotates an image that should not be rotated. Thanks.
Fargo is a new browser based outliner that syncs with dropbox. Created by Dave Winer. Looks pretty cool. Very simple but I can see the power.
Introduction on Dave Winer's blog.