I’ve been following some of the recent posts about Windows 7, like here and here. I found this choice quote in the Office UI Bible.
"Something we’ve known from usability tests for several years now is that most people don’t click on an unlabeled 16x16 icon. Sure, Bold and Italic and Center and a few others get a lot of clicks, but the curve falls off after the first 8 or so. As a result, we try to label every command in the Ribbon. "
What struck me as interesting was that when faced with the problem of too many tiny icons, the MS Engineers’ first solution was the complete the opposite of mine. Removing the buttons from the toolbar that are not being used is the obvious solution to me. Instead, they decided to add labels to everything. And so, the hugeness of the ribbon was created to accommodate all those new labels. Grouping and tabs were then created in an attempt to make the labels shorter so that more would fit. And so on, until you end up with this.
I think their solution comes from a mindset that is fundamentally different to that of most Mac developers. Their solutions to problems is always to add more stuff. Obviously this is the only available solution sometimes, but in my experience, removing complexity is often the the better approach.
I’ve been walking through all my old email looking for comments and suggestions about Collage. Of course there are some really strange ones, but some of the suggestions are great. So I’ve been doing my best to add things in. It’s mostly very subtle stuff, but after making all those changes it’s starting to look quite a bit better. Check out the change list below for more info on everything.
This is a *real* beta. It probably has bugs. If that might frustrate you, hang on for the final version.
If you do find bugs. Please report them to me via email: Report a Bug
In my experience 100MB file size is about where things get questionable. Sometimes sites can get much bigger if (1) they are not media “heavy” and (2) they are using very simple pages—like mostly styled text.
If you’re using photo albums, collages, or carousels, then 100MB is about where things start to go downhill. My guess is that’s it will open, but when you try to publish (which sequentially loads each of the pages into memory—and *tries* to purge what it can afterwards)—things hit the wall. Probably you hit your total physical memory—or perhaps even the ~3GB limit for 32-bit apps. Either way, RapidWeaver likely hangs or crashes with a memory error (sig 10/11) or—the best case scenerio—you get a “this page is not working” sort of error and the publish fails half way through.
I doubt I’m giving you much new information—but just to help others that are following along. And, as you’ve already identified, splitting the site is a good solution.
I’ve only had to split one site myself, this is how I did it:
1. Make a plan. Try to recognize some common hierarchy of your site. Is there a way to make way of dividing up the content. Keep in mind the goal is often to divide up things so that you’re splitting up the memory hungry pages (things with images or movies). If you don’t have many of these sorts of pages—you’re probably dividing because you have A LOT of pages—so then your goal is just to get a nice even distribution.
When I did my dividing, I had three product groups. Although there were links from the homepage down into the groups, there were not so many links between the different pages. This made it relatively straightforward to find three main groups.
2. Make a backup. Before starting any real work, you’ll want to make a backup of your site file. (the file that has the .rwsw extension). Back it up and move it to a safe spot. If all goes wrong, you can start over from square one with the backup.
3. Make some copies. We’re going to need a new rapidweaver site file for each of your new sub-sites. The quickest way to make these is just to duplicate your original site. For me, that meant duplicating my site file 3 times. That gave me 3-subsites—and I used the original site as my top-level. Give them each nice names so you can identify which sub-site they are.
4. Configure a subsite. — Open a sub-site file. — Delete all the pages, except those that are part of this sub-site.
5. Create some internal links. For me, there were several places where I needed to refer to a specific page that would be part of the home-page, top-level, site—pages that I just deleted in step 4. Rather than typing these links in manually over and over again. I created a “Offsite Page”—then configure that page with fully qualified URL—then when I need a link to that out-of-sub-site page, I just link to this offsite page. This not only makes building the links a whole lot easier, but much less error prone, and as a bonus, if that page happens to move someday, you’ll only need to change the URL in one spot. — Note: You may want to open the page inspector and tell RapidWeaver not to show this page in the navigation.
6. Repeat steps 4 and 5 for each sub-site file.
7. Open your top site file and do the steps 4 and 5 for it too. — For me this created a problem. The problem is that when you open the top site, there was some nice navigation to all my subpages before—but I just deleted all those pages—and with it, the navigation!!! What to do! — More offsite pages! — In my top-site file I created an off-site page for each of the deleted groups. I let RapidWeaver use those pages in the nav bar to build the navigation as usual. And for the links on my homepage—I can just link to the offsite pages—just like we did in step 5.
This process for me took about half a day. The basics get done quickly, but I decided to take the time to walk through the content and look for links that had been broken. There are always a few here an there.
My experience is that this not only serves to speed up RapidWeaver and make everything more stable, but also has the added benefit of emphasizing some clear organization of my content. For me, this was a big win. I like orderly things, but chaos is always trying to sneak in and ruin my day.