A bit reluctant in a way to raise this because the quality of Adam’s documentation and general support is so good.
But, I would find a documentation index useful.
An alpha list of the stacks in Foundry, Thunder Pack and Alloy Pack stacks regardless of which of these they belong to.
Perhaps in a footer where I can click/tap to go straight to any stack’s documentation without having to work my way through Foundry (and its sub-sections), Thunder Pack and Alloy to find - as the extreme example - the Zoom Stack.
3 Likes
Good morning @Phloque –
The reason it is not done this way right now is to avoid confusing customers about which stacks are in which packs. I don’t want to accidentally give a customer the impression that the Zoom stack, for example, is included in the main Foundry bundle. If they’re all lumped together in a list it gives the impression that they all come together.
Since the packs each have their own separate section in the Stacks Library, where you choose the stack for dragging onto your page, it made sense to me to organize them in that same way to prevent any confusion for customers.
Hope that gives an idea of where I was coming from with that.
3 Likes
I have “only” 216 or so stacks from various vendors (most from Foundry) & have the same problem with no simple lists of stacks. So I copy pasted stack names and links into an HTML document, just to have a 1 page, all stacks, linked list for my quick reference. Also made a spreadsheet of all stacks with keywords, descriptions, my category & few other columns & created a text file which I can search. Don’t know as my list would be useful as they are all my stacks, but you’re welcome to it. One thing I did find were some errors in Stack modules, listing incorrect URLs for Info pages. Even the latest stack Equalize, has no direct doc link (at least not on my version). I can almost always find the documentation through Google, “Site:http://elixirgraphics.com Equalize” for example, reveals Equalize Documentation. Even info on deprecated stacks can be located that way. It’s super hard to get up to speed on all one’s stacks with no “index” into the information. On Adam’s Documentation page (Foundry Documentation) he has left-nav that quickly accesses all his stack’s doc pages, by name. There’s a web site https://hamish.com/rwstacks/ where he’s listed his stacks in a “Filter” stack and produces a “Searchable Stacks Library”. …Bill George http://williamcgeorge@gmail.com
2 Likes
Thanks Adam, sure do see why things are as they are in your documentation.
But I think BillGeorge’s idea is brilliant - a database/spreadsheet of all my stacks (not just foundry) with links to documentation and a description of what each stack does.
More laborious than using a spreadsheet/database, but might be fun trying to set up a RW project using Foundry’s Seek and embed/iframe stacks to have the documentation for each stack right there in RW.
Thanks for the links and kind offer to share your own setup.
All the best
Philip
What would be lovely is if @isaiah could build a stack “audit” feature into Stacks - a one-click info printout of all loaded RW stacks (would also be good if it was possible to filter to show which stacks are used in a specific Project file).
Maybe just a CSV export…
3 Likes
I’d forgotten about the “gear” in the stacks library details window - the one which lets you make a stack a favourite, add it to a Group, and “Show online info.”
With some developers clicking on this option takes you straight to the on-line documentation for that particular stack.
1 Like
In general I agree the navigation in the documentation could be better. I am often not sure what I want and browse through the stacks. Having them sorted by how they are sold isn’t helpful at all. The way the tabs close is clumsy, especially when I am going through all of them to find an idea on how to handle something.
Selling is a temporary choice (but or not buy), but using them is permanent, so sorting based on how sold doesn’t really make sense.
I’d also like a screen shot of the stack in the documentation. Sometimes you just need a quick reminder of what it does. The video is better for more info, but if searching for something a pix is a time saver.
Lastly, I would like a training video on best practices. For example, something that explains when it is best to use (or combine) group, container, and the other stacks that control other stacks formatting in generic ways. What is the best to use and why? What is designed to work together or best avoided? When building a page with multiple stacks, are there any rules of thumb to know?
A generic word search of the documentation would be a huge improvement.
I think part of the problem is while that might make sense for you, when stacks are included together like that, people make purchases thinking things are together - which adds extra support work to a single person dev shop. Every minute Adam has to waste going through the process of explaining something like that, or going through refunds is time he can’t be spending doing development work, which is what brings in more revenue.
So how do you balance that? Keep support for each individual product within it’s sale sections is one option, or having a support setup where you can access everything, but it’s clearly de-lineated, (like Foundry Documentation) is another. I think it’s a good compromise option and lets Adam spend more time focusing on development and not dealing with annoyed customers who think they’ve been misled. I would think a lot of Adam’s customers are repeat customers, as they expand their stack portfolios, so that first interaction is so incredibly vital.
1 Like
Sometimes when you are a one-person shop it is hard to get an objective perspective, too. Been there, done that.
The question is if support documentation’s focus should be sales or supporting previous sales. I purchased everything he sells because the price difference isn’t that big, so for me, the separation is very capricious (and confusing somewhat, since the names mean nothing to a newbie).
It would certainly be easy enough to add a master documentation link where everything is combined. Plus, if someone is looking for a solution, whether they bought it already or not, they would be more likely to find it if they only had to search in one location.
There is also the still bigger issue of us being webdesigners and making always better interfaces for users to access more and more information easily. I went with Foundry in large part because I liked the documentation. It reveals an orderly mind which I appreciate. Other stack developers do a not so good job in this area (understatement). So, just to be clear, mine is not a major complaint but I certainly understand what the original poster is referring too.
I think Adam can manage his own time productively without fear of some suggestive feedback. He obviously developed a system that suits his workflow, but the time may come when he wants to change it for some reason and he should know what we users think. His success still depends on pleasing the customer, the same as any business. If marketing is the #1 priority, that’s more reason to do it differently. As it is now it’s unnecessarily confusing. Color coding the documentation by packaging would be one way around this issue. There are likely others.