Will keep a closer eye on all versions, any startup bugs are a no-no. Hope you get to try it and share your feedback!
Update: I pushed a new UX build, hopefully that addresses it, but otherwise let me know! I added the support email in my profile.
I actually cannot see the issue in my Mac Mini with the App Store build. So any more details would be hugely appreciated. Thank you!
There’s also something really weird going on with the window. When I have your application open and I hit ⌘Q to quit, it minimises. Bringing it back to the foreground doesn’t have a menu bar; the Finder menu bar is visible. Then after a while, the window goes away but I see it’s in the menubar. Don’t play silly games like this please.
When I chose to download the Mac universal build from your website using Safari, a new blank tab opened and nothing happened. I closed the tab, returned to the original page, and saw a permission prompt asking to download from your website.
The manual download version does have the `static_themes` directory.
For what it’s worth, I don’t like downloading DMGs manually. In order of preference: Mac App Store Homebrew manual download.
Regarding the static_themes missing, you are correct.. I will submit a new store build for this one! Hopefully folks are not having issues that prevent them from loading the app, and not consistently.
On the topic of window state, the goal of dismissing the app to "Tray" is to lessen the perf hit of startup cycles, for example when the configuration is fetched (which contains the theme list, bought addons and so on) and to support the Autoblogger addon (which, when enabled by the user, can be configured to create posts at a schedule). I do send an OS notification right away (something to the effect of "PRSS is still running in Tray"), but I agree that the UX is not perfect yet. Based on your feedback I will explore better ways to support these scenarios. Thank you!
By the way, as you keep exploring the app. Please do continue to send your feedback on here or the email attached in my profile page. Feedback like yours is really appreciated, I generally get very vague feedback in Feedback forms. Thanks again.
Thi is something that is normally done by asking the user first.
> I do send an OS notification right away
This isn’t effective because when your application is run for the first time, it doesn’t have permission to send notifications. So when the user tries to quit for the first time, they won’t be told it’s still running, they’ll get asked to receive notifications. You should use something other than notifications for this.
Is it your own static website builder or did you consider using an existing one?
What type of model are you going for here? I can't see anything about pricing, but I see text encouraging users to "reach out to support".
I was previously using WordPress and thought something that runs on my desktop with a pleasant UI could be better. I had some thoughts on how the interface should be and the features that would be cool to have.
Regarding the model, there are addons for purchase within the app (for example, different editors, scheduled AI-assisted blogging, etc). But all are fully optional and will remain that way. There's also a new "book-style" theme that folks can purchase, but the free ones are very professional also. I encourage users to reach out to Support because it's the early feedback phase and the key is to understand what are folks impressions with the product and any features they would really like to have.
So overall, the goal is UX and Developer Experience first, and further on there will be improvements and new offerings based on people's needs. Thank you for your feedback!
I'll be honest if you want feedback - as a developer I'd prefer a solution that builds on top of an existing open source static site builder. That way us devs can carry on using the tools and deploy options we know but our less technical colleagues who just want to put up a new blog post can use the nice CMS experience.
A tool that requires we switch the entire site building process over to it is a harder sell. Sorry to be negative!
I think the question to figure out is: What would be a way to keep PRSS simple for the average person, but powerful enough for Devs? Currently the approach is to have the preset build system (to reduce third party dependencies and bugs), but provide the ability for devs to fork themes locally and use them in PRSS (this is supported).
Ideally folks should only need to download PRSS, and have the Wizard to automatically setup Git and the GitHub CLI, and then PRSS would take care of the rest. But as I hear of folks use cases, it brings some good perspective. I will definitely think about these further! Thanks!
Before PRSS, I used WordPress and thought the concept of creating sites could be simplified and improved. "Press" was vague, so PRSS Site Creator was the alternative that came to mind, and for which shorter domains were available!
But I do agree that "PRSS" doesn't exactly roll off the tongue. I hope that the "Site Creator" part of the name combined with good user recommendations can help with visibility on search engines.
Similar use case to PRSS.
yuppiepuppie•7mo ago
"Error: ENOENT: no such file or directory, open '/Applications/PRSS Site Creator.app/Contents/Resources/static_themes/slate/manifest.json'"
and
"Error: ENOENT: no such file or directory, scandir '/Applications/PRSS Site Creator.app/Contents/Resources/static_themes'"
errors.
Also, just a bit of feedback, your developer name on the app store is a bit sketchy <random digits> Canada Inc.
volted•7mo ago
About the developer name, we tried to get Apple to use our "doing business as" name, but no dice. But thanks, it's very important to know what the first impressions are, to remove friction as much possible.