I'm trying to better understand user experience by seeing what users are doing on the site. There are various tools out there that will work to track the clickstream, and record pageviews, generating heatmaps etc.
However, they don't seem to work with meteor. Since meteor is not even using ajax - it's data over sockets - and I think the tools do not support this newfangled magic.
I was wondering if anyone has found a remote recording/click tracking tool that works with meteor?
For example:
- http://www.luckyorange.com
who have a note here about hooking into the browsers XMLHttpRequest.prototype.open but that's not gonna work with meteor and more socket level protocols, it seems.
mouseflow.com also just recorded a white screen.
crazyegg.com doesn't even support ajax.
There are some other mobile specific tools like:
- http://www.uxrecorder.com/
but that would require native SDKs. First off I just want to put this up for the web.
There's one company https://lookback.io/explore who actually develop their desktop site in meteor, but they are mobile/iOS only :(
it's quite time consuming to try these out so it would be good to know anyone else's experience, eg:
http://www.getapp.com/alternatives/mouseflow-application
How are people doing remote usability testing of meteor sites?
Mouseflow does work with Meteor, though you might need to enable some extra features in the Mouseflow dashboard. The most notable would be the enhanced tracking mode, Session Support, which is necessary to track Meteor pages.
Additionally, it might be necessary to block some scripts from being loaded in playback, but that is something the Mouseflow crew can easily do from their end, if you contact them through the support links.
Disclaimer: I work for Mouseflow
After trying all the tools, I found inspectlet
http://www.inspectlet.com/
and had no problems integrating that with meteor. It's a new tool and seems to be designed from the start with Single Page apps in mind. Overall their tool is quite minimal but does the job really well and seems to work flawlessly with meteor. They're also a startup and were very responsive on other questions.
I created a small wrapper meteor package around Inspectlet and other a few other useful metrics toolkits, if anyone is interested I'll publish it to atmosphere (let me know here).
Related
We about to build a mobile app which displays static content made up of text, images and videos. For what it’s worth, it’s a social enterprise in the field of mental health.
We want the content displayed in the app to be driven by a CMS, so that it is easy to collaborate and update the content without needing to release an app update. Normally I would just set up something like Django and expose the content via some REST endpoints.
However we’re keen to build a really great offline app experience, so the app is going to need a cache of this content one way or another.
I’ve been looking at Realm, Firestore and AppSync which all seem brilliant in many ways, but I’m wondering whether they are overkill for something like this, as really what we need is just uni-directional sync, not the bi-directional magic they provide. I’m also slightly nervous about using something that isn’t as mainstream as REST (we once built something using Parse.. before Facebook shut it down).
My question is therefore are there any simple, widely used, reliable technologies or design patterns which solve the problem of syncing a cloud CMS into a mobile app data store
?
Its really easy to have websites fully in javascript without having to do any page reloads between urls thanks to HTML5 location and frameworks like Angular. Why do new websites not completely go with no page reloads?
There are several reasons why someone would not want to, all of which are opinion based so there is no true correct answer to your question. Some of the reasons include
Not wanting to adopt new technologies. After all the old technologies work fine.
Server side rendered sites typically will still mostly function with javascript disabled
With a SPA typically you need to use something like pre-render.io or some advanced prerender system that uses browser versus server variables to tell if you are rendering from the server or browser.
You are making an API
You are making a very simple app that does need lots of components and advanced functionality
SPA technology could quite frankly be considered unstable because there is no clear way to implement it perfectly with many solutions. Older technologies may be considered more bug free like python which has been stable and bug free for over a decade. Spa technology is being continuously developed and improved with no clear path to completion. Many people will not invest the time in it because they do not believe it will be the web 2.0 solution.
I am building my app in phonegap. In that app I am calling my wordpress website like window.location="http://www.example.com/";.
Because of window.location my app UI and mobile browser UI are looks same. So I want to detect phonegap app to defer from browser UI. Is there any way to do this.
#JayTh
Okay. Thanks. VERY GOOD TO KNOW. I spend hours getting beginners to understand issues. You got them.
Okay, once you load a webpage from a website you are NOT allowed to access any of the Cordova Plugin APIs. However, you can access HTML5 API, like camera and geolocation. Again, you cannot access any of the Cordova Plugin APIs, and any of the 800+ 3rd-party APIs.
The best way to access the web, is via inAppBrowser. However, the third paragraph states:
The InAppBrowser window behaves like a standard web browser, and can't access Cordova APIs. For this reason, the InAppBrowser is recommended if you need to load third-party (untrusted) content, instead of loading that into the main Cordova webview.
Apple is serious about their security, so if they detect you are going around this, they may reject your App. Just to be clear on this, there is a new security protocol, which Phonegap Build now requires, and so does Apple. With Phonegap Build, it will create the required Apple ATS entries into the Info.plist.
So, the best I can do at this point is give you three (3) links.
Top Mistakes by Developers new to Cordova/Phonegap
Core Plugins Setup
HOW TO apply the Cordova/Phonegap the whitelist system
On 1., you have hit #5 When designing the app, thinks phonegap works like a website or webbrowser.. For the remainder, I recommend just reading the bold sentences.
On 2., if you want to use the Cordova Plugins, it is best to use the version numbers, if not you will get the latest, and your code may break. This is because now, Phonegap Build now uses NPM for the plugins. And many times bugs fixes get into the plugin, that require the latest compiler - and Phonegap Build is always at least one version behind.
On 3., You'll need to use the whitelist to apply the fixes that maybe required for any new plugins you are using.
If you have more questions, I can answer them in comments. If it get too complicate, we can move to Google Group of Cordova/Phonegap - Best of Luck.
I was looking at some larger scale Meteor applications and was wondering why some of the initial sites do not seem to use meteor.
As an example when you go to classcraft and look at the main website you notice it is not using meteor.
Then when you go to their actual application (click signup for example) you can see it uses Meteor.
So they make a clear separation in terms of technology. Can someone explain the reasons? Is it not as efficient / clean to just use Meteor for the whole thing.
Thanks,
Jean
Each company makes their own decisions on how/when/where to use technologies. In the case of meteor, the really strong part of meteor is that it's real-time updating. That means things like messaging systems, getting updates out quickly, etc. good uses for meteor.
It appears as though classcraft has decided they don't need that capability on the home page. There's also some concerns with SEO and meteor that perhaps classcraft didn't want to deal with.
Finally the home page not being built in meteor shields the DB from public view, which is not a huge security advantage, but may be one they considered.
This is all me finding reasons for them as I don't know why they'd make that decision. I don't make that decision for my sites/apps but that doesn't mean others might not see things differently.
I'm the founder of Classcraft. To answer your question, it's because we didn't need everything Meteor had to offer for the front-facing website : reactivity, flexible templates, a database, etc. Meteor is amazing for building apps, but it's overkill for a static website. Also, if the front-facing website was built within the game app, it'd mean that any copy changes or tweaks to the front-facing would cause us to have to redeploy the app, which means some downtime (not much, but still) for our users. Keeping them separate also allows marketing people (who aren't developers) to tinker with it without going into the code base for the game.
We decided to build the front-facing website using middleman. Middleman allows you to generate a precompiled static website, which allows for amazing speed and simple server configuration (it's served from S3, which means it's super fast).
I'm sure the reasons are different for everybody, but that's what it was for us.
Shawn
I am considering creating a website with the complexity of Facebook that should be able to scale into the millions of users. My question is: Is there any reason not to use Adobe Flex for such large project apart from the obvious point of requiring everyone to have Flash installed and not having to rely on Adobe? In my view Adobe Flex would reduce the server load for Facebook, because more of the work could me done on the client side. Do you agree?
Of course Facebook could have been implemented in Flash. But then the question is would it have succeeded? There are reasons big web companies like Google, Facebook and Yahoo only use Flash as sparingly as possible.
The thing I would fear most is alienating users. The Flash plugin isn't the best piece of software out there. It is slow and likely to crash once in a while. If your app gets bigger you might get some loading times that might not be acceptable to your users. Also in my opinion full Flash sites just don't feel right because they behave differently from HTML websites. All great websites like Google, Flickr, Stackoverflow or Facebook feel very light and slick which is very elegant makes up for great usability.
And then HTML and JavaScript are a lot more flexible. Do you want your website to be available on smartphonse? The iPhone has no Flash and even with phones that do you have the problem that users will very likely hate a full Flash site since those phones don't necessarily scale Flash as nicely as they scale HTML and Flash draws battery like crazy. If someone comes up with another revolution like smartphones you can be sure it supports HTML and JavaScript but you can't be so sure about Flash.
Then the question is how would you gain any efficiency? Of course you can write your UI with Flex and just call very lightweight webservices like you would use them for AJAX and you can even cache some of the content of the site locally so that you don't transmit more data as necessary for user interaction (the UI is transmitted only once). But you can also do that with JavaScript. You can write your UI in HTML and JavaScript, load it once and then just pull the naked JSON data from the servers and render it using JavaScript. You can also fetch lots of this data in advance to get the number of requests down. But still such an approach has its cons. Did you ever notice that when you type an answer on stackoverflow and someone else submits an answer you get notified while typing your answer. Such real time features are very cool and you might want this at some point in time which means more server interaction.
But whatever you do your servers still have to scale if your site grows. Even if you minimize the number of GET requests that hit your servers they will still grow a lot when your site gets popular and you will need a lot of servers to handle you will just improve your users/servers ratio.
The most interesting point though is that Flex is much easier to program than AJAX (think about browser incompatibilities for instance) and still AJAX was not only invented but the whole world messes with all those problems that come with it instead of using Flex. I think this tells a lot about of the value of the result you get when creating a full website in Flash.
Go to facebook and do view source...do you see all that JavaScript? That all runs client side
Johannes is right to point out the difference for server vs. client. The server side stuff is what needs to scale.
As an example, the Microsoft Silverlight team has assembled a facebook client app in silverlight (using the Facebook public API). My point is, using todays technologies, it is entirely possible to write a web application targeting many different kinds of client technologies: classic web browsers (HTML/javascript), 'rich internet applications' (flex, silverlight), ...
See also the myriad of Twitter clients out there.
The company I work for has a large app in Flash that is used by Governments. It is very hard to maintain and does fail sometimes. The problem is all of the .fla and .as files that have to be altered just to make a small change. Yes, the app could have been built better but even so, it is still harder to maintain than an HTML/JavaScript front end.
While I love writing Flash/Flex apps, I believe they should complement a site and not be the site.
Using a good JavaScript framework like jQuery takes the Browser compatibility question out of the picture (for the most part) and allows a lot of functionality.
Flex is the GUI for the client. You still need server-side storage and that's what has to scale. The user interface could be in Flex, while most of your users won't like such interfaces.
You will have to do a custom version of your site for the iPad/iPhone.
There are other ways of moving load to the client side. Javascript will give you porting headaches, but less than moving away from the entire architecture like Flex.
OTOH when you get a million users you'll have the resources to reimplement your site.
I don't think you would see a performance advantage with a site like Facebook, because the content is highly dynamic, comes from many different places, and is created by many independent entities. Flash (and therefore Flex) is better for monolithic apps from a single source that don't need to change very often.
The default in Flash is to build everything into a single .swf file that holds everything. It is possible to break out of this default behavior, of course. You can make web service calls, pull in external components via the SWC mechanism, load static content via HTTP, etc. Nevertheless, it's not the default pattern, which affects how Flash development libraries and tools work. Besides, the more of this you do, the less of the "run everything we possibly can on the client side" benefit you get. It gets soaked up in HTTP connection overhead.
The default on the plain old standards-based web is to store all assets separately and assemble them dynamically at the client. This is one reason the web is slow -- again, all that HTTP connection overhead -- but also why it is flexible and dynamic. It mates well with a site like Facebook which requires constant evolution by a lot of independent developers.
I say this having developed a Flex app, which I am happy with. Only one person -- me -- has to maintain it, and it's naturally a monolithic app. It plays right into Flex's strengths.