We'd love your feedback!
We're currently working on improving our default themes to be fully responsive (ie. mobile-friendly), and would love to better understand how you customize the FoxyCart templates, what CSS and layout frameworks (if any) you use, and a few other quick questions.
If you have a few minutes, we'd love to hear your thoughts:
Click here to participate in the survey. Thanks!
fc_adam
FoxyCart Team
I never considered you guys trying to make your part responsive,as I assumed most would change the default templates to suit their own styling within the website.
Maybe I am wrong
We want to get a little more feedback before we share our plans, but part of our thinking is that we'll provide a "Wireframe" theme, which will allow for easy inclusion of your CSS framework(s) of choice (ie. select "Twitter Bootstrap" and the class names in the Twig/HTML are what you'd expect for Twitter Bootstrap; or Foundation or Skeleton or 960.gs or etc.).
What we're trying to make sure is that what we do here serves 3 different types of users:
1: Super light (if any) customizations of the checkout.
2: Inclusion of the checkout into their own template, but no customization beyond that.
3: Full customization / integration.
#1 and #3 are pretty easy, conceptually. The trick is meeting the needs of all 3 types of users. We'll update more as we confirm (or change) our plans based on user feedback
Just a suggestion
But I did it with the best of intentions ... the suggestion like.
It is a great suggestion - the focus of snippets has generally been on javascript based stuff, but with how we're planning to develop the new approach, there is definitely scope for a repository of helpful HTML and CSS based snippets for templates.
As a responsive devotee, I'm not huge on frameworks, generally speaking. The primary reason is that not all breakpoints are created equal. Your breakpoints generally need to be decided up on based on the specific nature of your page's content. Most frameworks are just a tad bloated and unnecessary (especially stuff in the vein of bootstrap).
Lastly, I find the cart to be one of the trickier aspects to develop resonsively. Colorbox isn't responsive by default, so it currently requires some hacks to get going. I would love to see a transition to a different modal plugin that is responsive out of the box (unless of course colorbox becomes responsive out of the box...). That would be life-changing!
Lastly Lastly, it would be awesome to see less use of images all around. Images for headers and buttons has always been one of the more time-consuming aspects of Foxycart templating, and now with retina displays to be concerned about, it gets even worse. If these were live text by default, that would streamline templating for most folks. And for those that want to use images, they can have at it.
Just my two cents. As a regular FC template-er, I'm generally a happy man
@nickff We're actually planning (and already have a proof of concept) moving to PageSlide, which is responsive. (It's also something I've wanted to add to FoxyCart for about a bajillion years, so I'm excited to finally get it. And it's fully JSONP, no iframe, which makes it a lot faster and potentially easier to style.) Ultimately we want to have a few different "minicart" approaches that are pretty and easy to drop in, but we're focusing on getting one really solid first.
As far as images: Yes. When we did the default "standard" template it was 2007, and font-face wasn't even close to a possibility. But yes. You're right
All that cart stuff sounds brilliant. Some minicart options would be so rad. I've developed some simple cart messages here and there, in lieu of colorbox firing, but more ideas there would be sick. And pageslide is an awesome idea. I actually used it here and loved it.
And sounds good on images / font-face. With the growing library over at google fonts (and all the other pay-for font services), that will be a great change to make. SO stoked!
Could you link us to your site (perhaps make another thread about it) where you were having troubles getting the third-party cookies to work? It definitely should work no matter what modal you're using, as long as your passing the cart session ID through correctly. We would be happy to take a look and see why that might not be working for you.
[edit] I spoke to soon, I see you've already done just that!
Don't use any frameworks and instead focus on the little usability/performance things that matter. Text titles instead of images, making sure form fields have proper html5 attributes "email, number, etc". Making sure items degrade gracefully. For example, make sure that country autopicker works on different phones
I also often wonder if the visual cart is really even necessary; doing away with it and creating easy back and forth navigation from the checkout to the site would eliminate one user step and potential reduce bounce.
FWIW, you can achieve that already - simply include a cart=checkout parameter with your add-to-carts and it will jump straight to the checkout. One key thing to note with that approach though is that once a customer reaches the checkout, they may be less likely to go back to the site and purchase more items. That's just my assumption, I don't have figures to back that up - but certainly an interesting thought.
Are there any updates regarding Foxycart using HTML5?
We're currently in the midst of our new template rebuild - and as part of that we're completely rebuilding our checkout markup to match current best practices - one of which is incorporating HTML5.
For what it's worth, it is currently possible to convert the existing templates to use HTML5 elements using our Twig templates: http://wiki.foxycart.com/static/redirect/templates
Do you ever publish your development queue?
I'm wondering where :
1) more advanced user management to lock client users out of sensitive code
2) sales summary data visualization
3) font-face file caching
sit as priorities vs. template responsiveness? I haven't built in responsive templates to my stores as yet, but from what I've seen, it seems it would be possible to do within the existing framework.
Thanks!
Admin user management and sales data visualizations are somewhat related, and are likely inclusions into an admin rebuild that is currently scheduled (related to getting our new API publicly released and documented, which is currently scheduled as the priority after our upcoming release).
Font-face caching is something we looked into last month, but unfortunately it'll require a bigger change to our caching system than we can handle right now. (We think can make it work with everything but IE, which doesn't play well with our current approach. I've just reopened that discussion to see if it's something we might want to do anyway at least for the interim.)
So… we aren't super public with what we're doing, mostly because we _really_ dislike over-promising. But we will let you know what's on the immediate horizon, and/or if something just isn't going to see our attention in the near future.
Does that help?
When developing css for a site, I also never use frameworks - I always write css from the ground up, based on my own little css library that I tweak per project.
This is off topic - In the foxycart admin area, is it still necessary to have the "cache your url" and "update template" buttons. To save time when our site has been changed, it would nice just to click one button. It would be even nice if Foxycart just knew the receipt or checkout template had changed.
With an upcoming admin rebuild, that is one thing that will be changing.
Thanks for adding your thoughts.
I should probably clarify my earlier post - I was meaning that we were heading in the 'one button to update your template' direction rather than the 'the system knows when you change your template' direction. That would indeed be cool, but not something that is being included in our admin rebuild that I'm aware of
It'll be v2.0.
It'll have a similar early beta release, probably a very short private beta before it's available but not the default version for new stores.
We thought we'd be done with it, but we aren't. We have all the design done, about 92% of the HTML and CSS done (everything except the receipts), the huge bulk of the back end done, a new unified javascript event model done. We're working on connecting the front-end functionality, so … no timeframe, but absolutely moving forward. We're also trying to get better at estimating timeframes, but right now we're still not very good at it