Apologies for the delay - at current any technical issues will be reported by myself or another of the core team to the development team. I'm not sure what may be different in the future, if we'll have any technical resources direct on the forum or not, but we really appreciate all the work the community has put in.
I can't see how this is going to work (and so far hasn't) – the community are happy to contribute, I'm sure, but not when there isn't a desire from the core team too. I actually don't recall seeing one technical issue resolved by the Perch team yet?
One of the reasons your competitors like Craft, Statamic, Kirby etc are doing so well is because the support is so good, and you can interact directly with the devs. Having to report technical issues to a middle-man (no offence) is yet another layer of friction that Perch could do without. A massive pain-point for Perch users over the last few years, has been the level of support (or lack of) but somehow the new team has found a way to make it worse.
Saying how much you 'appreciate the support' and 'thank you for your patience' is just becoming condescending now. Perch has very little goodwill left within the community and at this rate it won't be long until it's depleted.
I look forward to another non-answer in due course.
Agree on not using 'Likes', in-fact, I personally think you should disable the ability to like a comment entirely. It just adds noise to the forum without any meaningful contribution. I'm not opposed to voting on features but it should be done in a place where you layout a possible roadmap and get users to vote there.
Perch previously did this by using Trello for Shop features, but unfortunately development was so slow it was a pointless exercise. But something similar might be worth considering, or even just using GitHub issues.
Another thing that came up in the past was the reluctance to look at what other CMS's or platforms were doing. When users would post to the forum that CMS X does Y, the response was usually "we don't have access to that and don't intend to look" so we'll do it our way. This is a bit shortsighted, especially when that particular feature might have already been solved in the best way. How the developers of a CMS wouldn't have local installs of all their competitors is beyond me.
Apart from any critical updates, the whole UI should be top of your list. It's like going back in time whenever I login into Perch haha.
As I said we are monitoring the forum and will drop in from time to time and my support colleagues will be engaging with you to ensure a free flow of communications. It is important as you highlight to keep in touch. We want the forum and the product to blossom under our new helm.
I'm not quite sure you're grasping the concept of support.
It's getting ridiculous now. Although, it is starting to become entertaining to watch how badly managed this has been. You're certainly setting an example of how not to do things when running a software company.
Just answer some questions directly, without posting another message that doesn't actually say anything.
It’s nice to see that the lack of involvement in this forum by the owners also means the negative comments are not deleted.
You're assuming they're reading them... 😂
I don't think it's as farfetched as you might think – if they managed to get it for a low-price (which lets face it, Perch wouldn't be worth much in its current state) then they may of been hoping to make their money back plus a bit on top through residual sales. Pretty easy money if you don't invest any time back into it, which quite clearly they haven't.
What a farce Perch has become.
The level of incompetence and complete lack of respect from both previous owners and the new ones astounds me.
All I can assume at this point, is that Perch was acquired with the sole purpose of squeezing out the last few licenses from the user-base before shutting up shop. Any response (or lack of) to this that is along the lines of “something is coming soon”, or “we’ll update you as soon as we can” will only confirm those assumptions I’m afraid.
The following questions need answering immediately:
- What is happening?
- Why aren’t you responding to questions in the forum?
- What is the roadmap?
- Why haven’t any updates whatsoever been released?
- Why aren’t you part of the Slack community?
Although I’m not developing any new projects on Perch (for obvious reasons), I’m now at the point – unless something significant happens very soon – that I’ll be actively contacting my Perch clients to advise that it’s time to move platforms as soon as possible. That is a lot of sites. I can only presume this will be the case for a lot of other devs too.
The core principles and potential of Perch remains, but without the trust of your users, that means absolutely nothing. Even if Perch 4 is miraculously released today, there is so much additional damage control needed to start rebuilding any level of trust.
What a joke.
I do find it a little odd that there are requests for code to be handed over many months after the sale of the company, even if there is a handover period.
Having worked in this industry a very long time, all this talk of “Project Managers” and “technical handovers” doesn’t fill me with a lot of confidence.
Not one update has been released since the acquisition, which is a really bad indicator of what’s to come. If you’re in discussions to buy a CMS, surely you’d have at least a developer ready to go...
A lot of this apprehension about Perch would be nullified if the communication just improved. I'm completely sympathetic to the situation – it's hard to justify time to a product that isn't currently sustainable – but at the same time, it's not unreasonable to expect the product creators to be a bit more active in the community. Answering a handful of forum posts every couple of days, tweeting a Perch thing or two, or dropping into the Slack room now and again is not too much to ask.
Moving the codebase over to Github and letting the community contribute would be a great way to help move things forward. Both Craft and Statamic (amongst others) are doing this with success. You could trial this with V3 while you work on V4.
I don't think you're alone Ryan – more and more of us will be considering our options over the coming weeks and months. The lack of communication is unacceptable now.
Unless we get an update and some reassurances soon, then going forward – as clients need updates – I'm going to have to advise that they move platforms. I've already got several big projects lined up for this year and I just can't justify choosing Perch at the moment.
format="M jS, Y"
Valid points, but I would add that they are now are having to change the pricing model as Perch as it is, is not sustainable which indicates something somewhere isn't working. And it's not always down to how you price your product or service.
This is of course all conjecture though, and like yourself and others have noted, Drew and Rachel are the only ones that know the details. Hopefully, if nothing else, this thread will help them decide on the way forward.
I understand why they've positioned it like they have, and why they chose to use that tagline. The low barrier of entry for less experienced devs is one of the things that sets Perch apart.
I do believe, however, that by combining the two products, they could easily market it as a CMS and a set of tools that lets you do the simplest of things very easily, as well providing the depth of utilities to build out more complex sites like we know it can do.
Absolutely, if the ratio of Perch-to-Runway is currently skewed towards Runway then this doesn't make much financial sense.
You make a good point about the tagline too – I think this probably does more harm than good.
Locking the licenses after a year is essentially the same as paying for updates after a year though isn't it? Or are you purely referring to how domain assignment should work? I wouldn't mind this, although I can think of some edge cases where a business wants/needs to change their domain; but I guess on those occasions we could reach out to Perch and request a license migration?
Some good discussion here but it's all irrelevant if the communication, support, and update frequency doesn't improve.
100% agree hus_hmd. Collections can already replace some existing apps but I like the idea of optional templates for less experienced devs.
Regarding the subject of monthly/annual subscription – by switching to a standard subscription model, I could see this being the final nail in the coffin for Perch. However, using the approach where you only pay to get updates à la Sketch and Craft, is a much better compromise I think.
I also think they should consolidate Perch and Runway. Have one price for the Perch product (somewhere in between standard and Runway as it is now) and you can then choose how you wish to build your site. They will lose a bit on runway licences but make it back on standard Perch, which I would hazard a guess is the better selling one anyway. This would also come with less overhead to manage two separate products, and let's face it, £50 for Perch is too cheap.
I'd like to echo everyone's sentiment here – I'll be more than happy to pay to renew a license every year to get the latest version – BUT, like Stephen says, I'd want assurances that support and update rates are going to improve. 1 update in the whole of 2019 is not okay in my opinion, especially when looking at competitors who are pulling further and further ahead.
I'm now choosing to work with other platforms out of concern for Perch's future but would love a reason to use Perch again more frequently.
Also, just a little bit of transparency goes a long way. You will lose more customers by staying silent, instead of just saying: "sorry folks, it'll be another 6 months, but here's a sneak peak of a new feature". We all work in an industry where it's commonplace for anticipated dates to slip but poor communication is far far worse.
Perch is a great CMS already and has bags of potential; and with a bit of TLC from the core team and the right tools for the community to build some amazing apps, it could start making ground on other popular CMS's in no time!
If this is seen by Drew or Rachel, then please consider a short reply acknowledging this thread (or even just a tiny blog post), it would certainly go a long way to reassure a portion of the Perch community.
Well you're in control of the block wrapper elements, so couple nth-of-type with the direct descendant selector and it can't break. I think you're right though, that it's not possible at a template level.
If you wrapped each pull quote block in a different tag than anything else, such as a q or section, it's not exactly semantic, but then nth-of-type would work.