I don't think its that. Its that AMP is borderline an anti-trust. But the point is, even with the speed and possible ranking boost, does it boost conversions? More traffic without conversions generally does not help an e-commerce site.
Just look at this example: http://i.imgur.com/84FvZmA.png Notice how the news carousel is completely unrelated, and the pages do not otherwise show up in the search.
Also notice the awesome bug in Google where "Nazi flag" returns "Flag of Germany".
Oh, certainly for English results showing news results for that query is very, very relevant given what is going on in the US with people waving actual nazi flags. You can see that if you e.g. search for a flag that isn't in the news (like danish flag) there is no news result.
You’d think so. But many blogs and ecommerce sites have started dressing their content up so that it ends up in that carousel, even if it’s not actually relevant.
Google always ends up putting news from a sailing event from last year in that carousel when I search stuff about my city. Especially awesome in Google News & Weather, where 90% of the news are from last year.
Google seems to just displays the top X search results that happen to be AMP, no matter how old they actually are.
That said, an antitrust complaint was filed with the EU anyway, so we can all just hope your employer is forced to end AMP sooner rather than later, and we can all replace it with a solution that doesn’t rely on any single group’s implementation.
Yeah, but load speed is, and imagine how skewed and unfair it is for Google to load an AMP page from its own cache and compare that to loading a page from someone else's (possibly objectively faster) site. And Google doesn't consider AMP pages cached from sources other than Google to be real AMP pages.
The carousel ranks in position one if it is determined to be the best result. It can rank way below. https://www.google.com/search?q=facebook is a good way to see that.
Original article was about e-commerce. The Top Stories carousel is not relevant to e-commerce since it only contains news articles.
You're taking the guidelines for the Google AMP Cache. Do you have any sources showing that an AMP page hosted by CloudFlare is demoted compared to on hosted on Google?
First, how is it anti-trust? And second, it's been shown that faster page loads = better conversions since your bounce rate drops. This is especially true for mobile.
Imagine the scenario, a user lands on the AMP page and a user lands on a responsive page. Both have a question about shipping time. The AMP user has to navigate to a contact form to ask, then submit. The responsive user can just ask in the chat window on the page.
> The AMP user has to navigate to a contact form to ask, then submit. The responsive user can just ask in the chat window on the page.
Why would you use an AMP page for that? It was specifically NOT designed for those use cases.
Now back on your point: if the users who have a question are a small % of the total users, why would you have all users load the heavy chat window on mobile devices with limited screen space?
I appreciate your optimism, but my read is that current Google management is very heavily invested in this idea and will fight hard before they give it up.
In addition AMP has penetrated other platforms, like Facebook, Twitter and Pinterest.
The cat is out of the bag, and it will not be easy to put it back.
The cat is out of the bag, and it will not be easy to put it back.
Yup, now that those damn users have gotten a taste of speed & low data usage, it's gonna be hard to drag them back to how it used to be. We had a good thing going, and they didn't know any better.
The author of the article being discussed expressly states that AMP is bad because it doesn't allow chat services or 3rd party integrations. Those are two examples of things that often lead to a bad experience and large downloads.
>I imagine it will likely be shelved soon either by lawsuit or just by Google's closing it down
AMP isn't going anywhere so don't get your hopes up. But, by all means I encourage you to initiate a lawsuit if only to see you fleeced by a lawyer for your litigious attitude.
Also, the article you linked to is so full of inaccuracies that it's impossible to take it seriously.
Oh? So how do I get into the AMP carousel on Google search without implementing AMP on my site?
This is a major ranking factor, in some situations moving sites that would be on page 13! to the #1 spot in search. In other cases, the effect is less visible.
That is what keeps people from not implementing AMP.
And you get this ranking benefit not for using AMP, or for a certain performance, but it is given to everyone that uses Google’s AMP version, from Google’s CDN, with Google’s tracking solutions. If I want to run AMP from my own CDN, I can’t do it, and if I want to avoid Google’s cache, because I have my own CDN, I also don’t get the ranking boost.
I don't have a "source", but that is accurate from what I was told by the team behind AMP. In order to make it into carousel, AMP content has to be served from Google cache.
There is no direct source, but you can try it, or just look at the current implementation.
Currently, Google serves AMP by serving all AMP search results from its own cache, which allows Google to add features such as the header bar, or the swiping between carousel elements. This doesn’t work if the pages are from different origins.
> A: No. By using the AMP format, content producers are making the content in AMP files available to be cached by third parties. For example, Google products use the Google AMP Cache to serve AMP content as fast as possible.
> Anyone can use a CDN to set up and run an AMP cache, but only content in Google’s cache (which Google has stated can be used without restriction and at no cost) is currently getting preferred search results treatment
But the whole point is kinda moot because AMP requires that your assets be "cacheable", which means google will come along and cache them, and the search results will use the google-cached version.
So sure, another CDN could cache your stuff, but nobody clicking through a google search result will ever hit it.
> How different is this from common HTML caching done all over the web? And that's about using the Google AMP Cache, not about using AMP.
> And you still didn't provide a source about "having to use Google's CDN".
This is the issue I meant with Google’s CDN/Cache.
If a user clicks a link to an AMP page in Google search, they are not redirected to your page. They ALWAYS get the cached version from Google, and Google modifies your page by adding UI, and changing other functionality (for example, the left/right swipe gestures are changed to navigate to other Google search results).
You can not opt out of this while still appearing in the carousel.
Could you show us some examples of AMP sites served from Cloudflare (and not the Google AMP cache) that show up in the Google AMP carousel and get the AMP logo in the Google search results?
Maybe they don't follow their own docs and there are sites out there not cached in the Google AMP Cache that still get placed in the carousel. I have no way to prove that without being able to test every single possible search term (plus all the other variables like location which affect the results).
And yet, you only get a ranking boost if you allow Google to cache your page on their CDN. You can not run your own modified version of the AMP js, or run AMP’s js from your servers, or opt out of being cached by Google’s CDN and get the ranking boost.
To quote the AMP specs, a page is only eligible for showing up as AMP in search if it
That is a bad thing to say. We need help, its a huge project. Its not just rewriting a few lines of code, there is a whole infrastructure behind the software we need help in setting up.
Then why say you guys are official and remove credibility from all the other forks? I know that's not your intention but you used the word official because "these idiots on the Internet will pay more attention to us"
I can own that, it was me. We decided to launch this on Wednesday and I am a poor designer. I needed something to quickly get up as a page to explain to people what is going on. So I grabbed a Jekyll theme and went to town. Sorry about that, I am kind of at fault. Here is the theme I used though, http://jekyllthemes.org/themes/space-jekyll-template/
Remember mystery meat navigation? This is even worse: invisible navigation. Hiding the navigation behind a hamburger is OK on mobile because it’s an established pattern there and the screen is smaller so you perceive the entire screen readily; but on desktop computers? I didn’t even see the hamburger.
We have the GH organization created. Its all private for the moment.
Basically we have never forked a software like this before. We are going over the license and trying to make sure all our i's are dotted and our t's are crossed so we do not end up in a lawsuit.
The project will totally be open source, it will be under the same license that the code is currently under OSL 3.0.
We aren't trying to bait and switch I promise. This is something we have been talking about for a couple of months, but we decided on this week. So when we open the repo to the public to help with we just want to be in a position we can defend if it happens to go to court. Nothing kills a good idea faster than an opening day lawsuit.
However, I think after reading the comments below that the scope of the project is to maintain backward compatibility with the agencies/authors of plugins in the Prestashop ecosystem.
What we were looking for is something that was trying to do new in the webshop ecosystem. Even I misjudged your "lack of MVC" comment below. My perception was that you were bringing together a lot of people from the Prestashop community and building something new with modern day best practices.
Using an ORM is the smallest of them. MVC is another. asset pipeline could have been a third.
But if you attempt any of this.. you will risk breaking backwards compatibility with any number of plugins out there. Which is why I'm doubtful you will try to do anything new. The way I see it is that you will maintain a bugfixed release of Prestashop 1.6 with incremental changes to support the plugin ecosystem out there.
Personally, I think you are aiming too low. You want to make something better than Prestashop 1.7 which is why your holy grail is to maintain backward compatibility and fix some plugins (like the Paypal one you talk about).
But from what I have seen, your real competition is the Shopify of the world. Even Magento 2. Not sure if you have seen the docs, but Magento 2 has started adopting best practices out there:
Let me be honest, I am winging a lot of this because you guys are asking great questions. I think I am either not expressing our plan adequately or it is a bad plan. I don't know, its late friday night and I have been having a couple of drinks after a hard week.
We are going to end up rewriting things with better practices. This is something that HAS to happen. Its not the first thing we are going to do though. We need to build a userbase in the cheapest, quickest, easiest way possible. Not having to scrap everything, getting a more stable shop with new features is attractive to people.
I am purely looking at this from a business sense. Yes, we can take the code, we can convert it over 6 months to be something totally different, more robust, better designed, just bad ass code. In that time we can miss the window and not have as many shops migrate over to our platform. Thats not a good strategy in my mind. I see great ideas all the time on GH that have been abandoned because they are not profitable. We are trying to cut a middle line deal here in the beginning. We want to make a profit to pay for expenses and we want to give merchants what they want.
Once you have users in a platform it is easier to get them into a big upgrade than to try to get users from scratch, or get the to migrate. I realize (I think) you are looking at this from a purely code / application development stand point. Look at it from a business stand point. Merchants generally look at two things when evaluating a platform. Is my payment gateway accepted and are my shipping options accepted. If we break these things out the gate we will either be stuck writing all of these modules, or we will just lose those customers. On the other hand if we get them to migrate and have a grand plan later, the agencies and companies that keep up these modules will rewrite them. I am trying to mix logical business with logical development to come up with a successful plan.
look i understand your struggle. but you will HAVE to make a call.
your points below about "not having to worry about zero days like wordpress" and "not having an MVC" is incompatible with your statemnt of "we will do bugfixes for next 6 months and go from there".
I would even go to the extent of questioning any success you think you will have with the bugfix approach.
Prestashop inc has 9 million USD of funding. Your reason of existence will vanish the day that Prestashop fixes the few bugs that you have. What do you think will happen then ? Will you yourself continue on this fork... or will you say "oh well, the Paypal module works on prestashop 1.7 again"
If you are doing this, then do this for the reason you want to do it subconsciously - all the MVC stuff you are dreaming about.
>Once you have users in a platform it is easier to get them into a big upgrade than to try to get users from scratch, or get the to migrate.
There is zero incentive to stay. The advantages of your "new" platform are so minimal that people will instead make and buy new plugins for 1.7 . In fact sorry for being blunt, but the existence of your fork is just as long as it takes for all agencies to port their code to Prestashop 1.7.
If your users migrate, they will force you to never break compatibility. So you will basically become Prestashop 1.8 . There is no possibility of a grand plan later.
I really think you are pulling an outsider looking in on this. PrestaShop HAD 9m in funding. It was wasted on deploying a cloud which is being shut down on Feb 1. It was wasted on a myriad of other things.
As someone that works in depth with PrestaShop, very in depth, I don't think they can do it. I talk to the founder regularly, I actually emailed him and let him know we were forking. I believe in that kind of courtesy still.
Let me ask you a simple question that might change your mind about things. How many developers do you think work on PrestaShop? Currently the company has about 120 employees. 4. There are 4 core developers. Out of 120 employees 4 developers. I know all of them. I respect them. I don't agree with them sometimes, but jesus I know they are regular guys in a shitty position.
I think the bug fixing approach will work. Maybe it won't. That is what I am betting on. Like I mentioned before, I am just one person in a machine being driven by other people. Sign up to our mailing list. When we release the code as OS we are going to have a gitter, we can all get in it and air our opinions and hash out a way forward. I am expressing my ideas not necessarily the ideas of the project. I will argue my case and if I lose I am going to do what I can to help the idea that wins. To me this is what being a community is about. We are working with a product that is under a totalitarian regime I feel. I am not leading people out of one into another. I am the first to say I don't have the best ideas. We want more collaboration. We want people from outside the Prestashop ecosphere to come in and give ideas. In the end these are things that will help us.
You should worry about it, and fast, as every professional and actually usable and maintainable setup uses one, and your refusal to use one, thus relying upon a patchwork of unknown stuff from unknown sources, is one of your biggest exploitable (as in I do it to clients while testing their network every day,) vulnerabilities.
So far, I've moved a lot of people, including my own online auction company, off of your platform because getting AJAX code to work reliably with it is near impossible due to lack of object-relational mapping.
I could go on and on, but quite frankly, you need to start from scratch. Right now you're just trying to slap a lot of icing on a poorly-made cake.
an ORM will help you write more maintainable code in general. Every framework right from rails to symfony uses an ORM for the abstraction it brings.
Some of the security issues in wordpress - unescaped queries, SQL injection and everything - which plagued it for decades could have been avoided by using a well tested ORM.
I would urge you to make this one of the highest priorities in your code cleanup. It is not going to take you a lot of effort, but the long term advantages are too many to enumerate here.
For example, for your own development sake - I dont know how you plan to manage schema changes. If you use Propel, you will use "database migrations" - something that every framework from Rails to Django, etc mandates as best practice.
I understand it, but look at it from this point of view. PrestaShop 1.7 requires everyone to purchase new themes and modules. The code base is extremely messed up.
We are taking the PrestaShop 1.6 codebase that has 10k modules and 2k themes as a fork. If we go changing the database handling off the bat we are going to lose the compatibility that might make us successful. We aren't a project starting from scratch with unencumbered code. We need to maintain compatibility to be successful in the beginning. We are springboarding basically. You are wanting us to take the springboard away and just jump.
A simplified version of the roadmap is this. We are going to fix bugs and stabilize the platform where people can sell without having daily bug fixes.
After that we are going to pool our knowledge, resources, and community to figure out the path forward. I will be totally honest with you, I am half developer half CSR person. I hear what my clients want and I try to make it happen. I am not the only person in on this though. I am one of many and very flexible. We are going to do a rewrite after we have stabilized things and we are going to do it right. We are going to look at the options out there and figure out where to go.
At this point it looks like I am leading things. I am the reluctant leader. I am the guy that realizes that my ideas might not be the best ideas and I want to hear yours. I just feel in the beginning it is about stabilizing what is there. I think if we spent 6 months rewriting everything we would lose an important window.
Tonight I am actually setting up the feature voting for our site. This is how I think things with a community need to be handled. There are going to be nay-sayers that stifle things because they are new and unfamiliar. This is always going to happen. But if we are transparent and add features by simple voting then no one can really argue with the logic. I have my ideas, but I am not the arbitrator of what will be included. I really want this to be a community project. I want the merchants and the developers to speak what they want and I want to make something that reflects the ideas of both.
We are not. We are actually spread out all around the world. Right now we are not a company, we are just agencies / developers that mad, sick and tired, and want something better. We just started this project this week and we are pulling more and more agencies on board, it is exploding under us.
About the Paypal. For me personally that is a reason we are forking. Last year the company that develops the Paypal module for PrestaShop got into an affiliate fee dispute with Paypal. They released an "update" of the Paypal module that basically made every UK shop's module disappear on the checkout for customer. People in the UK had a shit fit. I mean who releases an updated module that is meant to punish users to prove a point to Paypal? Totally unacceptable.
I find it missing a lot of things personally. Its just a mash of plugins from different sources that have not been evaluated or secured. The package itself is pretty light, because it does not have the features of other actual ecommerce packages. You have to use plugins that were not made for ecommerce packages to extend it.
A good case in point is most dedicated ecommerce platforms have one thing in common. User login and admin login is handled by a totally different system. This is a security feature. At the same time, most platforms support multiple sites or shops out of the box. Woo supports it with a plugin that was never made for ecommerce.
The lack of an MVC ... I digress. Wordpress is awesome for blogs. For something that takes money and has liability I don't want to have to read 0-day lists every day and see if I need to comment out something or update. Its counter productive to business.
