I’d love to have Sparkle 3 show some page counts. Sparkle 2 showed the number of pages in your website indirectly: when creating a new page, the default name was “Page xx”. The default has changed in Sparkle 3 and I have no way of knowing how many pages my site has (it was 364 at last count).
I’m attaching a suggestion on how/where to display page count.
I really need this too!
My website http://theviews.org has 144 pages, way too many for Sparkle to handle in 1 project. I got the count by searching the local on-disk site for every file that ended in .html
I would recommend against having multiple Sparkle projects.
It would become a nightmare to maintain in the future. My site was spread over 28 Sparkle projects and I spent nearly two weeks full-time consolidating them into a single project, and it has been worth it for sure.
My site is now about 12 gigabytes in about 5,000 files. Sparkle takes minutes to open it and every time it publishes it to disk, every .html file is touched. The images directory is now at about 3,000 items.
The “Life at the Views” section will grow indefinitely as well.
I’d like to keep it as one project, but it’s just too much for sparkle to handle and I haven’t gotten anything from the Sparkle team indicating that they are going to add site management features to it.
We are definitely aware of the pains with larger sites. What Sparkle feature would make your life easier?
Perhaps the least intrusive solution would be to add a site management window with a graph of the site’s various subproject like this (based on my http://theviews.org site):
Then Sparkle would only have to update each subproject’s files.
But that’s not really how the web works. Links can be in any direction, there’s no hierarchy. It is in fact normal for pages to point back to the home page, for example. Would that be an entirely synthetic view, independent of the site’s actual links?
Yes, it would be a synthetic view so you could navigate and update the various subproject’s easily. Sparkle would only have to have the subproject you’re working on in memory.
What I’m going to do for my site, since a lot of it is fairly static, is hand link buttons on the entry page to navigation pages like this 2019 Index .
Publishing my website as it is now in a single project requires a machine with enough ram to hold the whole thing. My big tower has 96 GB of Ram, so that’s not a problem for me, but smaller machines would have to have huge amounts of swap space.
I’m pretty sure that there are better ways of doing this, short of a full content management system.
What would the benefit be in having “subprojects” compared to having separate project files in the Finder?
I don’t buy the idea of having a different project view that needs to be manually updated, and potentially end up outdated compared to the actual page content.
About how Sparkle manages memory, it’s and entirely separate issue from how the UI is managed. Discussing the technical aspects of that here is pointless. Not to say we don’t understand it, or don’t have plans for it, but it’s a significant plumbing change.
We are interested in how to advance the UI for management of complex projects, but the synthetic view doesn’t feel like a clear win.
The subprojects would be separate project files. I just noodling around trying to figure out some way of looking at them.
The synthetic view was just a rough idea for some kind of way of collapsing all the pages that aren’t currently being worked. Even the collapsable section in the side bar aren’t quite enough to work with hundreds of pages.
It’s a really tough task to figure out how to handle web sites with hundreds of pages!
Agreed! We will find a workable solution. I think faster loading projects (regardless of size) and better organizational features in the page sidebar would go a long way. I’m not sure splitting up the site in different projects is of much use, except for the overall project file size. Maybe there’s some way to make a hierarchical view, based exclusively on the existing metadata.
I agree with @duncan about the graph not being very useful. I used the original FrontPage for years. It could show a graph of all hyperlinks in a site. I don’t think I used it more than once or twice.
For me, here are some ideas on what would help me manage a large site better (360+ pages and counting):
Better performance. Saving is sometimes fast, but sometimes takes over 5 minutes of spinning beachball. The UI frequently pauses for 2-3 seconds while I’m typing or editing (I’m using a MacBook Pro 16” with 32GB of RAM).
Color cross-referencing. The color palette is fixed. That’s a good thing IMO. I would like to add a color or two to the palette but I have no idea which colors are unused. If I edit a used color and change it, I’ll be messing up several pages. It would be good if Sparkle can tell me which colors are unused. It would be better if the search feature allows for search “by used color”. If it turns out that a color is used by very few pages, I can then edit those pages to free up a color.
Style sheets cross-referencing. Similar to above: I have no idea which styles sheets are unused and can be pruned. Unlike color, I can create as many style sheets as I want, but it does got unwieldy and I’d like to prune some. A search “by used style” would be helpful.
Sidebar based on actual folders. This will be even more important when I get around to adding multi-lingual support.
Some summary stats. I have no idea how many pages my site has. This is your low hanging fruit. 
I know I have over 3,000 SEO issues but again, I have no idea how many.
That’s all I can think of on this California morning.
I think you’ve presented a good example of how a large site such as yours can be handled in your It’s very, very big and your index is a great idea. I’d never thought of that, but for a site as large as this one you may want to be thinking of a table of contents much like your example.
The table of contents could be linked on all of your pages with a button TOC.
How about rather adding all the links on “construction” and “life before” and “life after” make the drip downs into months of the year. That would decrease the page count and make navigation a little easier.
This is an issue that I asked to be resolved at least two years ago…I’m happy that someone else has finally noticed.
Managing dozens and dozens of pages with Sparkle is pure madness and I think it’s not “healthy” to work in this way inventing systems that should be solved instead ahead of time by those who release the software.
But this is just my humble opinion.
It is also true that not everyone needs to manage many pages. I see sites created with Sparkle with maximum 7/8 pages, so I understand Duncan decides to concentrate on something else.
Let’s see what happens with version 4
I agree. Managing dozens and dozens of pages within a development environment is pure madness - no matter what environment is being used. My own company regularly creates websites with many sections and potentially thousands of web pages and we simply couldn’t do it if everyone involved in the process had to load the entire site structure into the development app in order to make a few changes here and there.
Essentially, site structure should be something that is mapped out at the beginning of a project. That structure can then be broken down into manageable parts and made the subject of a number of mini-sites within the structure. This allows individual team members (or a sole developer) to concentrate on individual parts of the website without having to load up a huge file into the development environment, and possibly creating problems across the site as a whole.
The concept of managing site structure within the development app itself was one that was introduced by MacroMedia in it’s dreamweaver product (now part of Adobe creative suite) but even this app, which is highly complex and expensive, required that you organise your site structure before getting into page and content development. Without this basic preliminary work, your site could end up a complete mess, requiring hours of tweaking and edits to get it absolutely right.
Fortunately, with the advent of modern web development apps such as Sparkle, the complexities of site structure and actual coding has given way to a more sensible focus on page development in a simplified WYSIWYG environment that most of us can understand. As @duncan has mentioned, there is no site hierarchy as such - we have pages and links, and whilst some may not see the need for separate sub-sites or separate project files, they do come into their own if you are struggling with a large and complex site.
Attached is a paper I’ve published before in this community (some time back) which sets out some working practices that help with the construction of more complex sites. I’m attaching it again for those who may have missed it the first time round. Meanwhile, I’m very happy with the way Sparkle functions as it is. There may be a few additional features we would all like to see, but I don’t think site structure is high on the list of priorities, particularly when this is something that should be decided prior to embarking on a website project.
Download link
Site Structure
I think every time we have talked about this, I have stated that we do think this is a problem that needs to be addressed, and that we will get around to it. Sparkle is missing many features, so we have to prioritize and work through the list. I think we have proven that we are still very much working hard on improving Sparkle, much to the dismay of other Sparkle users who are annoyed by the frequent updates and version number changes!
In think we disagree on whether our approach is healthy or not, I’m sure you are not suggesting we should not invent anything, to avoid growing pains?
We are incredibly proud of having enabled so many people in the world to create their own website, even when they consider themselves not technically capable, or beyond the age of learning. We are humbled by people who have been able to start a career thanks to Sparkle. All this despite the shortcomings, and in some cases even glaring missing functionality.
Sparkle 4 will not be everything to everybody, but it will have some solid and much requested new features, that will make many people happy. Possibly because they have been waiting for them longer than 2 years.
I mean no disrespect for your requests, and it personally very literally pains me that Sparkle is causing frustration and angst. I am thankful that we are having this discussion, because it means you value Sparkle, and all we really want are people using Sparkle happily.
No problem Duncan.
As far as I’m concerned, I think Sparkle is a blessing beyond bad page management.
I don’t know how many times I’ve asked you to fix this to the point, I guess, of becoming obnoxious. And I’m sorry, because I’m not at all, but as you say, if people ask for things it’s because they love Sparkle and I’ve loved it since day one.
I also understand that it’s not possible to please everyone, we’ll get over it and find solutions for what will be missing like our friend @francbrowne did for managing the many pages (thanks for the PDF, I’ll study it and then try to figure out how to organize my content).
FWIW, I do like having the entire site in a single document – as long as it loads/saves fast and the performance is zippy.
For me having my website in a single document is a no-brainer as opposed to folders/sub folders/files. Relative and fixed linking was a nightmare in the past and it was a guarantee there were always going to be issues with it. That is not the case with a Sparkle Document! 
I can imagine really large sites can be a task to create and maintain. For me I don’t go there, but with all created websites a good bit of pre-planning goes into it (as suggested by @francbrowne) to give the “end-user” an intuitive free flowing experience.
And don’t forget, you can always turn your “thumbnails” of allowing you to see more of your pages down the left-hand side…
That’s a terrific document on site structure.
Two questions occur to me, however:
How would one go about coordinating the site editing efforts of many individuals and teams for a very large site using Sparkle? Especially because Sparkle produces self-contained project files.
How would one reasonably approach creating alternate mobile layouts for each page in very large sites? Especially because Sparkle requires manual adjustments for alternate phone and tablet layouts.
As someone who long ago raised the white flag of surrender to the evolving complexity of website development, Sparkle has been a godsend. It seems perfectly suited for graphic designers who need an intuitive, visual tool for laying out small attractive websites. I love it for that reason. But I can’t imagine how one would use Sparkle in collaborative teams editing and managing a large website.
