Introducing Guzz, a live tutoring service built on Meteor

Hi Meteor community,

during the past six months, I created my first Meteor-based product called Guzz that went live in February. It’s a share-economy service that allows people to support / teach / mentor each other in 1:1 video-chat sessions. You can think of it of a mixture of Tinder (match-making) and Skype (live chat).

The idea actually came up when my washing machine broke down and I could not find any info on how to repair it on the net or Youtube - and finally ordered the wrong spare parts. Wouldn’t it be great if you could just grab your phone and show your problem to a DIY guy? That’s possible now with Guzz.

But the use-cases are not restricted to repairing scenarios, you can also use Guzz to find a guitar teacher, a programming mentor or a native-speaker from the other side of the world for improving your language skills. So it’s meant for usage scenarios, where traditional approaches (e.g. forums) do not really fit well, because you have to show / listen to something or where async communcation would just be too “slow” or inefficient.

One of the key features of Guzz is match-making between a person looking for help and a Guzz Guru (my term for “tutors”), i.e. the “Tinder” part:

Once you’ve contacted a Guru, you can make an appointment for a live session, and as soon as both participants are there, you can start the live chat (the “Skype” part, based on WebRTC). It’s mainly targeting mobile use, to make use of features that are only possible there. So you can, for instance, use both cameras of your device to show something. There’s also an interactive white-board (based on Arunoda’s excellent Meteor streams article), which you can use to draw something together.

Beyond mobile use, Guzz of course also supports Chrome or Firefox (with a web-cam).

At the moment, Guzz is completely free-of-charge, but I plan to add a billing option later, to allow Guzz Gurus to monetize their knowledge / experience, if they want to. This shall also re-finance the platform.

I hope you get the idea - I don’t have a fancy intro video yet**, so I thought it might be helpful to write bit about it instead of just posting the link. It would be great if you give Guzz a try and tell me what you think about it.

Chrome, Firefox, Opera

Any feed-back / ideas for improvement are welcome. The user base is mainly German today, as I first got friends & family onto the platform, but you’re more than welcome to change that :slight_smile:

To try out the live session features - which is important, because otherwise you’d miss the best thing - you either need two people or you can just use two accounts running in two different browser windows or mobile devices (beware of feedback loops in this case).

If you want to contact me via Guzz, you can reach me under the topics “Ableton Live” and “Meteor.js” (Tom B.)

Thanks for reading,
Tom aka Waldgeist

** Due to the current lack of a “real” promotion video, my kids created one on their own to illustrate the concept. You can find it on Youtube.

PS: Thanks to all those awesome community package authors. Without your fine programming arts this app would have never been possible. I am originally a front-end guy and before selecting Meteor I’d never thought I would be able to build such a full-stack, multi-device app myself. And a very special thank you goes out to @arunoda and his team for making mupx, which allowed me to deploy Guzz in just one day to AWS. Meteor and its community are just awesome!


Awesome job! I like the look and feel. Looking forward to trying out the app.

I tried (twice) to add myself to the mailing list on The loading icon just kept bubbling(?). Not sure if I made it on to the list or not. No errors in the console. I’m running Chrome 48 on OS X 10.11.

1 Like

Thanks for reporting this. Will immediately look into it!

EDIT: It’s fixed now, but you’ll have to reload the page in the browser to get the latest JS code. Thanks again for reporting!

I love the video and I love the Guzz Guru term. And the idea for the app is cool too, I could see myself using it.

Too bad majority of the people will be stopping the video after some 15-30 seconds, but it’s not something you can help.

Grats and good luck! :slightly_smiling:

1 Like

@brajt: Thanks for your kind words, you’re more than welcome as a Guzz user! Will also tell my kids that you liked their video. :slight_smile:

1 Like

Hey Tom, very nice app and congratulations for going live!

I am kinda in a similiar situation like you were a few months ago. We want our app as a mobile app on iOS+Android and as a web app in browsers.

Can you tell me what your starting point was? Some kind of boilerplate or guide?
I am guessing you are using Blaze as View layer? Have you tried React or Angular? If so why did you decide against it?
It seems like both mobile and web apps are almost identical and share 99% of the code? Are you developing two different projects for mobile and web app or is everything in one project (like in one directoy with Meteor inside)?
What parts were the hardest during development? Any big roadblocks?

1 Like

Bug: when I go from to to (which is rather strange by itself, i mean the /1 part) and then hit Back - I’m on again instead of

1 Like

Remember that few months ago it was a different Meteor reality, the support for both React and Angular wasn’t as good as it is now with Meteor.

1 Like

Thanks, I encourage everyone to report any bugs! But this one actually works as designed. The reason why I auto-add the /1 is that only this allowed me to make the paging mechanism (which appears when there are more than 7 gurus) work. I have to admit that I fiddled a long time with it, because I could not find a way to let FlowRouter treat /experts/ just the same as /experts/{page}. The only solution I found was to auto-forward to /1 once you execute a search. And the jump-back from /experts/1 to the main page allows a mobile user on Android to hit the back button. A jump-back to /experts would feel like if nothing happens. But all of this is surely not optimal. Any tutorial on how to do paging better is highly appreciated, I grew some grey hairs when I implemented paging in the app.

Been struggling wit it for a while myself. No grey hair, but still a waste of time. Catch: [Solved] - Flowrouter: generic vs variable route

1 Like

Bug: search doesn’t work for me. Aftah I type smth and press enter - nuttin happens.
Also, clear serch field sd be red and search button sd be green.

btw, how long it took you to write your app (start - finish)?

1 Like

I solve such things for params and queryParams by adding an abstraction layer for them, where I check the state of params and if they’re empty, the param variable gets the default value. Same goes the other way - if the param variable value is equal to default, I remove the param or queryParam.

Hi @chronixSC,

thanks for your positive feed-back :slight_smile:

To your questions:

I did not start with a particular boilerplate. The app is mainly based on good ol` Bootstrap and SCSS, peppered with selected elements from Materialize, SemanticUI and some jQuery components. Yes, that’s a quite strange mix, as it may sound more sensible to use only one of them. But in the end, I always came back to Bootstrap as the main UI framework, because it just did what it supposed to do, without any weird quirks (like in Materialize). I also tried frameworks that are better tailored to mobile devices (like Ionic and F7), but struggled to make them work properly, and in the end my dev progress was already too far to make a complete switch. I also wanted to address th browser as well, and the Bootstrap / SCSS combination just allowed me to do this. Maybe if I start another app from scratch again (and have a mobile-only approach), I will consider using a mobile-first boilerplate first.

Yes, you are right, Guzz is Blaze-only. I tried Angular before I came to Meteor. And I was quite confused by its over-complicated syntax / concepts. Between Angular and Meteor, I also tried Aurelia and loved its simplicity. But it was in an early stage back then, the performance was lousy and Meteor allowed me to go for a full-stack approach (Aurelia is UI only), so I switched to it. But I heard that Aurelia is quite usable now, and some Meteor folks are using it in combination with Meteor.

Regarding Angular 2: I had a brief look at it but have to agree with the founder of Aurelia that the syntax is just weird. They’re trying to nearly re-invent everything, including using Typescript as their preferred language. Though I am in favor of typed languages in general (JS is definitely missing this) and I see the benefits of IDE integration, the risk is too high for me that you get stuck in a one-way road. And the syntax, … just weird IMHO, already mentioned it.

Regarding React: I clearly see the benefits of React, and if I’d start a new app today, I’d probably try to go this way. But Meteor 1.2 came up when I was in the midst of implementing the app. In this stage, many community packages were not ready for React yet, and many people were struggling with implementing authentication or i18n on top of it. I am not the type of developer who loves experimenting with the latest stuff in a productive app, I rather wanted to keep up the great dev speed I got with Meteor and Blaze. So, although I knew that the community is turning towards React and even MDG was suggesting this (for good reasons), I stuck to Blaze. Another reason was that you cannot easily use jQuery components in combination with React. If you start from scratch, this might not be a problem, as the React community components got a lot of traction, too. But I did not want to waste any time finding replacements for the components I was already using and that worked fine. For Guzz, I will probably follow a slow transition path, i.e. start by peppering in some React when developing new functionality, but for the time being, I am still focusing on getting “business value” quick.

To be honest, I don’t have a real “feeling” about how far React has actually come in Meteor by now. I heard of many people who are really content with it, so it must work now. But what still concerns me is how good community package support is, e.g. for useraccounts, i18n and such. I guess I will have to try it out myself. But I would still recommend trying the React way first, since it seems to be the go-forward approach now. And I trust those community members who are actually way better developers than me, like @arunoda or @SkinnyGeek1010 for instance :slight_smile: I am just a front-end guy who tries to keep up with the tech.

Yes, nearly all of the code is shared. The only exception are interfaces to native Cordova plugins, like push notifications (based on raix:push) and WebRTC. So, from a technical point of view, I’d say this is quite optimal, since it avoids double-work. From a UI designer’s point of view, however, this approach causes quite some headaches, because it turned out to be quite challenging having the same UI for both browser and mobile app. The screen-sizes differ so much, so you either have to find some clever solutions to support both or you have to compromise. And I struggled a lot with the different capabilities of the devices. For instance, I had implemented some quite fancy UI elements like slide-out menus and such. But then I tried them out on my (quite old) iPad 3 and the performance was just lousy. So I refactored and made the UI much less fancy. This would be a lot easier if you implemented everything on top of a proven, performance-optimized mobile framework like F7, but then you have the problem to deal with the browser as an additional (non-mobile) platform separately.

Everything is in one project. But nearly all of the code is separated into custom packages. The main Meteor folders (like /client, /server) only include top-level code, like heavily re-used templates or the core SCSS styles. I can strongly recommend to follow a “package-first” approach, since this makes your app much more maintainable. Plus, you have a quite fine-grained control of which code goes into the mobile app and which into the browser app. You can even create packages that are mobile-only. Nowadays, I would even move my core templates into their own packages, because it helps a lot to keep an overview of your code base. And it allows you to easily share components between projects, using the global package folder Meteor supports. Not sure if all of this will survive the transition to NPM, since I did not delve into the new 1.3 world yet.

The biggest roadblocks were:

  1. Transition from Meteor 1.1 to 1.2. This nearly made me despair, and I needed several attempts to do the transition. The main reason was that I found a quite “creative” approach to mix SCSS and Bower components into my app. This approach worked fine in 1.1, but was completely broken by the changes MDG made to path handling in 1.2. Eventually, the solution I found now is much better (and helped me to better modularize my code), but the transition was (too) hard. I really hope that the transition to 1.3 will be smoother. I also have to say that many other devs had no problems at all transforming their apps from 1.1 to 1.2. Maybe it was just me and my “creative” approach.

  2. Internationalization: I wanted Guzz to become a global service from the beginning, so i18n was key to me. But at the moment, Meteor lacks really good i18n support (or I did not find the right package yet). I am using tap:i18n, which works quite well, but problems come up once you want to support both mobile and browser. The reason is: If there’s no network connection, the UI always falls back to the default language (which is English im my case). This makes a bad user experience, if you start the app on a mobile device without network. There’s a solution for this available now from the tap team, but I could not make this work yet (and did not have time yet to try out their latest fixes). Plus, for whatever reason, tap:i18n turned out to be quite unreliable when the number of text files exceeds a certain limit. I am facing weird behaviours, like some texts showing up in English instead of German. The only workaround is a meteor:reset of the project. Maybe this is also due to some strange bug I introduced by myself, but I did not find out the root cause yet.

  3. Performance on mobile devices. As described above, I had to make many compromises between usability (i.e. fancy animations and such) and performance, since I wanted to make Guzz run smoothly on at least an iPad 3. Besides this, performance on older Android 4.x devices is often much poorer than on new devices. This can be fixed by adding Crosswalk now (which brings its own Chrome component under the hood), but this was not compatible to other plugins I was using, so I am still using the default webview. But I will try to get rid of this as soon as I find the time to do so. React Native might be a game changer here, but as it forces you to tailor your code to specific platforms, this also breaks the one-code-for-everything approach, at least to some extent (you can still re-use a lot of code, of course).

  4. User authentication (sort of): I can warmly recommend the useracounts package, but still it seems as if it was mainly designed for browser use. For mobile devices, I had some trouble to make things work as expected, and I still have to find a way to really integrate social network logins. It might be me being too dumb, but the straightforward approaches did not work as I would expect and so I postponed this.

  5. Lack of built-in SCSS support. Meteor focuses on Less and leaves SCSS up to the community. The team behind fourseven:scss are doing great work, but it took some time until I could use SCSS again in 1.2, since MDG had introduced some breaking changes in this release. It’s fixed now, but I would love to see SCSS to be supported per default (and sashko already gave a clue that this might change).

  6. My own inexperience with Meteor when I started the project :blush:

But despite these “roadblocks”, I want to stress that my app would have never ever been possible without Meteor! I really love this framework, and still don’t see any alternative on the market that I could use. As I already said, I am not the “core dev” type of guy, and I would have never dreamed of being capable of building such a full-stack app before I came to know Meteor. And the best thing is that the community (including MDG guys like @sashko and @martijnwalraven) is really, really supportive. In most cases when I asked a question on these forums (or on Github), I got an answer in only a couple of hours, if not minutes. This is just amazing.


Interesting. Which browser are you using? It works fine for me on Chrome/FF (MacOS), iOS and Android, but of course I would like to know which combo does not work as expected to improve it.

Good catch. Actually, I want to re-design this in a way that it better matches the iOS and Android UI designs (i.e. using a grey x inside the box instead of a button).

The first concepts were sketched mid of October, and the first alpha version went live in January. But this is only part of the story, as I started implementing another app in May and could re-use some code from this. So I’d rather say, Guzz took approx. 6 months in total. And it also meant working until 3:00 a.m. sometimes :slightly_smiling:

chrome 49, win7. looking for Bike Repair

1 Like

OK, thanks, I’ll try that!

I tried your combination in a VM and it worked fine for me. The enter button works as soon as the search result is specific enough, i.e. as soon as something printed in grey shows up in the input box. You can also use the cursor keys to navigate through the result list and then select one of the entries using enter. Can you tell me exactly what did not work for you?

Yeah, now it works.

  1. It’s not obvious that you must select something from dropdown.
  2. Bike Repair didn’t produce any result last time i’ve tested it.

Strange. You don’t have to select it in every cases. This is only necessary if the characters you typed in are too generic, i.e. yield too many results. Typically, after two characters or so one of the results show up in the box as grey text, and then you can just type enter.