I'm hoping to test different versions of a form with Google Optimizer (Multivariate testing). The form is in an ASP include, but what the server-side code will load before Google's JS does. Any ideas about how to approach this? Thanks.
I think I understand your problem. The trouble is that Google's multivariate test is designed to allow you to test two or more snippets of HTML and the multivariate test itself is controlled via Javascript.
So I'm afraid the only way this will work is if you can specify the HTML for Google Optimizer to use for the two versions of the form. This could be made to work with basic forms, but if the form itself is dynamically created in ASP due to some other application requirement then I don't think Google Optimizer will work so well for you.
I think this helps you
Gwo Tricks
My answer is probably out-topic, but I guess you should implement the Multivariate testing by yourself in the ASP.
In the simple case, It is quite simple to implement on top of your existing application, so maybe this can do the trick in your case.
I've made progress on a similar problem. Basically, we want to A/B test 2 different page layout headers. There are some structural differences (it's not just switching out the CSS). We also don't want to wait for Google to flip the coin to determine which variation the visitor should see; instead, we want to choose the variation server-side and avoid a page redirect. I'm now using Google Analytics Content Experiments instead of the deprecated Google Website Optimizer. I don't know whether it's completely working yet, but my code is here:
Google Analytics Content Experiments A/B testing server-side code without page refresh
Related
I'm a React developer for front-end stuff and I've recently been given the task of evaluating whether or not Lightning Out (LO) or Lightning Web Components (LWC) can be used in our React web app for communicating with Salesforce.
We have some users who will not be able to log directly into our Salesforce instance, and so the suggestion of using LO or LWC has been made as a possible alternative.
As a non-Salesforce developer, I have a question which I don't seem to be able to answer easily:
Do either of these offerings from Salesforce come with any extra functionality other than the look-and-feel? What I mean is, if I add something from LO or LWC to a React app, do they have inherent capabilities for communicating with Salesforce to fetch/update data or are they just "dumb" widgets that look like Salesforce-native widgets?
Are there any advantages to using LO or LWC over any other UI widget library when it comes to working with Salesforce?
Thanks
First of all, feels like you are using LO and LWC interchangeably, so I wanted to clear that up first:
LWC: Lighting web components are are custom HTML elements built using HTML and modern JavaScript that use core Web Components standards. I recommend checking out their playground if you want to test them first hand.
LO: Allows you to run LWC web components outside of Salesforce servers.
I am facing some of these questions myself, and I had to do a little bit of digging. I will attempt answer based on what I gathered after some research:
Do either of these offerings from Salesforce come with any extra functionality other than the look-and-feel?
The short answer is yes. The true question is whether what's provided is useful in your context or not. For example, they claim that it delivers exceptional performance (although I found solid posts putting that in question), in part thanks to its "Lightning Data Service" (centralized data caching framework which is used to load, save, create and delete a record without any server-side apex code). These are some other things that Salesforce claims are made easier thanks to LWC:
Find solutions in common places on the web.
Find developers with necessary skills and experience.
Use other developers' experiences (even on other platforms).
Develop faster.
Utilize full encapsulation so components are more versatile.
Are there any advantages to using LO or LWC over any other UI widget library when it comes to working with Salesforce?
When it comes to working directly with Salesforce you wouldn't need LO, and yes - there's a very clear advantage to having LWC components as you can easily mount/compose those on any Salesforce page to get desired functionality fairly fast. Particularly beneficial if the System of Record for the data behind the components is Salesforce and you don't currently have a front-end for that data.
I've seen examples for both using React within Lightning, and LWC (with LO) on a standalone SPA. Now to my 2c: both look atrocious from an app architecture standpoint. In addition to that, it's a pretty clear vendor lock-in, so if you don't have the immediate need or mandate to use LWC, just don't use them.
If there are any LWC & React experts out there that care to expand and/or correct any of these, by all means...
What jinja2 can achieve, the same can be achieved with Angular.js. My question is- are there any advantages of replacing jinja2 with angular.js completely ?
I think most problems came from the same obvious difference: Jinja2 is server-side, Angular is client-side, this makes they really different.
SEO. Google don't understand Angular magics. It is just a heavy Javascript code and Google can't understand it fine. Sure, you have some workarounds to show your important text to Google, but to solve it you'll have to render some things server-side, going back to Jinja2 or some hack to render things to improve your SEO. (it is not important if you don't care about Google searches)
Performance Server-side rendering is way faster than Javascript rendering. I'm talking about your average user, maybe with an outdated Internet Explorer and a crappy internet connection. With Angular, you have to wait at least some Javascript assets to be loaded before the page is usable. Users notice this and we know a slow site will hit your conversions. Check this Twitter article about "time for first tweet": https://blog.twitter.com/2012/improving-performance-on-twittercom
Compatibility. Yes, they claim the framework supports all common browsers, but have full documentation about hacks to make it work for IE7. Depends of your audience.
Maturity. Jinja2 is really stable, has a pretty API and is deployed with almost all Flask websites. Angular is still evolving and sometimes things just change a lot.
Inexperience. You can't just replace Angular with Jinja2. When you try it, you will understand they are different and you must not work the same way with both. You will make a lot of mistakes before you make things right, just like with any new awesome tool you use.
Of course you can claim against all my arguments based on your specific needs, this is just some things you must understand before you go to Angular.
That said, I'm using Angular in several projects, mostly for single page apps. This is an awesome use case for Angular. In all these projects, I still use Jinja2 to some rendering, so this is not a complete replacement.
UPDATE:
Some updates almost two years after my initial response.
Google is better understanding dynamic rendering, but I still don't trust it.
I don't think the client-side rendering is a thing. Only realtime data is rendered client side, but the base HTML is generated server side.
Angular dropped IE7/IE8 support. It is definitelly a good thing for the web, but unfortunately I still must support these browsers in some cases.
Angular 2 is on the way, changing everything you know about current versions. I don't remember any major Jinja2 change.
Why is replacement your objective? Use the power of both Jinja and other server side frameworks together with the power of client side frameworks.
The benefits of using both:
less and easy code
better performance
more easy to maintain
and much more. You have a choice.
Choosing for one or the other will make your work frustrating and complex.
Does it make sense having a solution that uses both Freemarker and AngularJS?
I tried to convince everyone on my team of switching to Angular, and a more experienced developer than me pointed out that he prefers server-side rendering, which is both arguable and valid. But then he told me that if I still want to use Angular just use it with Freemarker instead of replacing it.
I'm a junior programmer, as far as I can understand they are designed to the same purpose.
It depends on the needs.
For example, if you want to break your page into individual re-usable components that you can tie based on some logic on the server side, then using freemarker or velocity for building these components makes sense.
The freemarker or velocity templates might in-turn use angularJS components that would be rendered on the browser and evaluated on the client side.
The server side templating would give you the ability to design re-usable angular components.
Now, some may try to use the Object component in HTML5 for doing the same thing, but this is not recommended as using Object expects a fully formed HTML element with its own <html> opening and closing tag.
Not something that is intended for a small reusable component.
As an example consider having your page header and footer in its own html template file that you would like to tie in for all the pages in your application.
As I google for Freemarker i realize it is just a templating engine. AngularJS is not a templating engine. Templating engine is just part within this framework. So both of them cannot be compared.
AngularJS is a full fledged framework for creating Single Page Applications (SPA). So if you want just templating capabilities on client side, i suggest you better look for some other light weight libraries.
If you want to use AngularJS you need to decide
Whether you can structure your app as a SPA
Does the site needs to be SEO optimized. Which has limited support in Angular or as a matter of fact in any client side framework.
Ready to use the AngularJS templating engine because it is awesome with its support for oneway\two way active bindings. If you don't use it templating engine you are loosing a lot.
No it clearly does not make sense as they serve very different purposes. All I can think of is that you either misunderstood the more experienced developer or he really has not understood the business case (WHY something is worth using) of using either technology. In my experience as a j2ee developer, I find that many server side developers (experienced or not) may not be too educated on the many new advances recently made in client side development. With Angular you are not limited to SPA. You need an insight into the overall architecture of your current project to determine if its a good fit. There are ways around the SEO issues or you can purchase an SEO solution. But clearly not a best choice if SEO is essential.
Unless it is a team decision and there are clear problems Angular solves for you, I would not suggest getting stuck alone with a new technology that only you know. Keep it as a hobby and when you really understand the best practices and benefits you can then try being an evangelist.
I'm wondering if anyone has found a solution to this problem. Is there a way to get the best of both worlds:
build a page-based site, with permanent links, accessibility, SEO, and graceful fallback / progressive enhancement (basically all the best practices of web development)
and, for those with javascript, a responsive front-end experience with ajax loading of content, no page refreshes while navigating the underlying site pages, minimal redundant downloading of scripts/content/css/etc. (all the benefits of a client-side framework like AngularJs or Ember.js)
I see a few major sites are able to manage this (gmail, stackoverflow), and I see that Jeff's new site builds a bare-bones version of the site in a noscript tag.
Is the solution to the hybrid page-based/single-page app to build two versions of the site, send both, and let the client decide which it can show? (is this what gmail does?)
Or is the problem that AngularJS et al. are simply not designed to allow for graceful degradation?
It hurts my DRY brains to think that #1 is the answer.
(The reason I am focusing on AngularJs is that I like its support for html templating, declarative style, and its attempts to fix js scoping. Ember and other frameworks are excellent too; maybe one of them would be a better fit for a hybrid site?)
This questions is a bit of a nuanced one because the answer is "it depends". For example you mentioned Gmail, there isn't any reasons whatsoever that an application like Gmail would need to be indexed for SEO, though depending on what you want or need to support you may want to ensure you can support not having Javascript.
However even the "no-javascript" argument is getting tired and weak these days, at least for the class of "web applications". If I want to use a Windows application I need Windows, if I want to use a javascript powered web application it isn't unreasonable to assume that I'm going to need a browser that isn't crippled to use it.
However back to your question I can only speak to AngularJS because I'm the most familiar with it. For the most part it does allow you to support a progressive enhancement approach, though don't expect to use things like URL routing if this is what you want to support. What you can do is use AngularJS controllers, bindings and directives similar to how you might use jQuery as a way of enhancing the interactions and behaviours of the page.
Just keep in mind this approach will seriously limit what you can do with Angular (or Ember for that matter) and it may start to be debatable what you are getting from this approach that you couldn't easily do with jQuery alone.
The alternative these days is to do what sites like Twitter are doing. That is basically serve fully rendered HTML from the server for any view on the initial load and then use Javascript for subsequent loading and enhanced UI behaviour. This is very effective (though perhaps quite challenging to implement) if you really need to support browsing with and without Javascript and has the added benefit of improve the rendering/load times for the first request. Again "it depends" because it depends a lot on how your site actually works if it is possible to use this. You have to design for it, and it isn't going to be trivial or easy.
Update:
For what it's worth we are taking the Year of Moo approach and rendering the pages that need SEO using PhantomJS and sticking the cached initial state of them somewhere to serve them up. We have a rake task we run on deployments to update this. Again this is just the initial state but it helps get around the issue for now.
Things are always changing though and I'm sure I will have changed my mind on this approach in a year or so.
Have you read Google's Making AJAX Applications Crawlable. You can have JavaScript single page app and crawlable content.
If you stick with angular, there is interesting article: Turns out it is possible to have your AngularJS application indexed
Ext JS is a nice framework for web UI, but I found that building and putting stuff together takes a long time and painfully slow.
This might be a general problem when working with JavaScript, but does anybody have any way to speed things up?
What can I use? Better IDE with good JavaScript suppport? GUI designers? Code generators?
I need some way to speed up common things like building grids and forms but yet let me do complex things like creating custom components easily.
I'm using ASP.NET MVC. Coolite seems nice at first, but I feel that I'll be having trouble when creating any custom components later on.
There's always Ext GWT, which lets you use Eclipse tooling (and all of the advantages that gives you, such as refactoring, swift code navigation, etc.) to create your Ext/JavaScript app.
When you download the ExtJs library, you find lot of sample applications for common requirements like Grid panel, forms, form elements etc.
Regarding IDEs, you dont find mature productive tools, but check the below link and wish it could be of help to you
http://www.extjs.com/blog/2008/02/01/ides-plugins-and-tools-for-ext-js-20/
But if you really wish to develop custom components, you need to get through knowledge,start approaching with ExtJs-provided sample apps.
If you want to get faster at anything, practice it until you fully understand how it works and how to make it do what you want. If you are just starting out, why would expect to be able to work as quickly as you do when you are working on something that you are very familiar with?
Things I use to make ExtJS less painful
Chrome, for it's developer tools, or Firefox with Firebug.
snipMate: snippets for Vim, so I can quickly produce boiler plate code for classes.
JSLint as a command line tool. Especially good for detecting rogue commas.
Sencha forums.
ExtJS IRC chat (Server: irc.freenode.net Room: #extjs).
API documentation.
Sencha and Saki's ExtJS examples.
Beer.
ExtJS is building a designer right know so you can look forward it, the only problem I think is not gonna be free.
you can see a video demo there, in term of release date I think this is due to the first quarter of this year.
I say learn the framework. But to develop apps, I use IntelliJ IDEA, which has partial code completion, etc. It costs money though.
Once you have some practice and understanding of how ExtJS works, you'll get faster at it. By using the examples for reference, and building up my application in small pieces, I've gotten much better (and faster) at developing stuff with ExtJS. A great way to get started is to find an example (or two) that kind of do what you need, and modify (or combine) them to see how they work together.