Mobile App Design: Horizontal Swipe vs Vertical Scroll to browse recommended users - user-experience

I'm developing a mobile app that allows user to browse a list of other users that was defined by a recommender system. The app allows users to like, dislike or just view the profiles of other users. So, unlike to apps like Tinder, user can view profiles of other users more than once.
I doubt what is the best approach to design a navigation for this app. I see 2 possible solutions:
Horizontal swipe between users in a Tinder style
Vertical scroll of users list
The reason why I don't think that the first approach is the best one is that my app is not a dating app like Tinder, it's more an app where user can find a people with shared interests. User doesn't make a decision using only a photo of other user, there are more information that should be taken in concern.
So, using the vertical scroll will allow user to see more content and more easily navigate between recommended users. On the other hand, horizontal swipe is quite a common approach will help user to see more details about other users profiles.
Did I miss some of the pros and cons of the both solutions? Which approach is the best for my purposes?

Let me try to put it in this way.
Tidner started revolution in terms of horizontal swiping. And right after us Tinder become the Thing, lot of copy-cats started to use "one-card-horizontal-swipe-cards".
In that time that was cool. Tinder did amazing thing terms of showing content only one time on the one card per user. For Tinder this works amazing.
In terms of your app.
If you want to present more than 1 user at the time, go with the vertical list.
If you want to have "bird-eye-view", go with the vertical list.
If you want to scale your app, go with the vertical list.
I'm not familiar with your product, but base on your description, you should avoid horizontal swipe.
Also, allowing users to switch between horizontal and vertical view could be good option in terms of A/B testing.
Best,
R
EDIT:
If you want to present those users as "recommended" as a object on the screen (e.g. User click on someone's profile, and at the bottom user is able to see suggestions) you should use horizontal swipe.
But keep in mind horizontal swipe should not be consider as a native human behavior in terms of interactions with mobile devices (not yet).
LinkedIn has a good solution for profile recommendations (vertical swiping). You should explore it as well.

Related

Multiple Displays (physical monitor screens) in React

I'm developing a web app using React and Leaflet, and I want to have it display in 3 separate physical monitor screens where I have:
the map in one screen mostly displaying ships on water
reports, details and options in another one based on what ship is selected
graphs in a third monitor.
I'm not finding information online as to what the best way to achieve this is.
I'm thinking of even doing three separate apps, but not sure how good that is. Or if I just have the user run the app in 3 different browser tabs which will be dragged to their respective monitor, but I don't know if this is practical or even desirable to have 3 instances of the app running this way, and then how would they communicate?
You see I have several questions, and I believe this is something that requires help from a React architect or advanced programmer, not something you'd find on the docs, and there doesn't seem to exist examples like this.
I hope the question is clear enough and that you can shed some guidance. I'm using Node.js and MongoDB in the backend of things.
You could create full screen functionality for each item, then open the same page on 3 separate monitors and on each monitor expand the item that interests you. regards

Reactive, long-running sequences and persistence in the cloud

I am to build a kind of website tracking system.
Think of a website where users click on various links – a unique user id and an identifier of the page tracks all page views.
Now, a single user might view 20 pages – some relevant some not. What I want to track is if a user follows a specific “path”. Example “Home Page” -> “Product A Page” -> “Get more info page” -> “Buy” -> “Paid”. There might be other page views in between each of these steps; the important thing is IF a user follows a given pattern.
In addition, I need to measure time between each step (each page view has a timestamp).
I have been playing around with Reactive Extensions, but I am not an expert in the area so I would like to hear if this would be a job for the Reactive Framework or if other technologies are more suitable?
I imagine a server getting a stream of website page views and then some fancy reactive LINQ queries that captures the events (this is where I need some help).
Next question that comes to my mind is how do you host this behind a load-balancer (on Windows Azure)? If you run two instances and the “Home Page”-page view goes to instance 1 and “Product A Page” goes to instance 2, how do they communicate about this or should some kind of sharding e.g. per userid be enforced?
Lastly, what about persistence? How to store? Should you store data in an Event Queue pattern and then load everything into memory when you “play back” from a restart of the server?
I know that were many questions, but I do love the philosophy behind Reactive Extensions; I just cannot get my head around how to “put into production in the cloud” :)
Thanks!
Casper
There are lots of solutions out there in this space already that you can integrate into your platform. Are you sure you're not reinventing the wheel? Google Analytics has functionality similar to this. If you need to go your own way, then SQL Server StreamInsight might be a better fit.
For behind-the-firewall solutions, Also look at http://piwik.org/ (free, open-source) and http://www.haveamint.com/.

How do you prevent phishing in mobile app?

Imagine a scenario in which a game X installed on your mobile device wants to access your account information from social network Y. Assume that Y exposes some API, and have features like "login with Y" etc. On desktop PC X could popup new browser window, with domain of Y clearly shown in address bar, with a padlock icon clearly indicating SSL connection, and in this popup, social network Y would ask user to provide login, password, and agreement to pass some information (like name, avatar, e-mail) to the application X. For example OAuth 2 uses this approach.
In my opinion, on mobile the situation is in rather different, as application X can take control of whole screen. In particular it can draw on the device's screen something that is indistinguishable from a real browser and hijack login and password provided by user.
How one can combat malicious applications which cover whole screen and pretend to be browsers, or even OS's settings windows etc?
There is no technological defense against this even on the desktop. It's trivial to mimic the look of a browser and draw a green SSL lock into a fake address bar. Or you can simply include a key logger with your application to get passwords entered any application on the same system.
For mobile applications including a key logger is harder. Drawing convincing fake browser window is easy. An additional defense is the review process of an app store. An official app store as the only source of trusted apps mitigates problems like this to a certain extent. While malicious apps can slip through any review process, they can be removed once they are discovered.
How about: double-click the home button so you see the app names?
You can also run task manager to see the app's name f.e. com.android.chrome. I think google won't allow in market two apps with same name.

What is the most efficient way to mock a user flow in a RESTful application?

How can I communicate in a very simple and effective way the path the user takes through my application?
I'm currently working in a Ruby and Rails environment, so I tend to visualize my application in terms of RESTful URIs. So for example, if I want my users to sign up, I could match a new route called /users/new. The thing is, I would like to see beyond that specific action, and visualize how many pages or forms does it take to create an account and some business logic associated with the process in general. In other words, I'd like to see a mix of a workflow diagram and some implementation details (at an interface level).
I was thinking in showing mockup pictures wrapped in boxes, and relate them through arrows with their corresponding GET, POST, PUT, DELETE methods and URIs attached to them. I think it is a good idea, but I haven't seen examples yet that inspire me.
In your experience, what helps you see the big picture? Balsamiq mockups allow to define links and navigate through the app, but it doesn't help to conceptualize.
Have you thought of using a mind-map? You could try the free FreeMind
If you stick with UML, you could consider an Activity diagram.
I think you're on the right path. Showing different screens with possible combinations of users' transactions between them is a good technique. Basically you would be able to show user's flow through your application and stress out decisions a user will make on the way.
The good example for it was presented here http://vimeo.com/43869717
This technique called Storyboarding. You should be able to find some examples. But the one I mentioned above is one of the best Storyboarding techniques. I use it all the time to show the big picture and present application workflow from user perspective to my team.

How can you ensure that a user knows they are on your website?

The talk of internet town today is the SNAFU that led to dozens of Facebook users being led by Google search to an article on ReadWriteWeb about the Facebook-AOL deal. What ensued in the comments tread is quickly becoming the stuff of internet legend.
However, behind the hilarity is a scary fact that this might be how users browse to all sites, including their banking and other more important sites. A quick search for "my bank website login" and quickly click the first result. Once they are there, the user is willing to submit their credentials even though the site looks nothing like the site they tried to reach. (This is evidenced by the fact that user's comments are connected to their facebook accounts via facebook-connect)
Preventing this scenario is pretty much out of our control and educating our users on the basics of internet browsing may be just as impossible. So how then can we ensure that users know they are on the correct web site before trying to log in? Is something like Bank of America's SiteKey sufficient, or is that another cop-out that shifts responsibility back on the user?
The Internet and web browsers used to have a couple of cool features that might actually have some applicability there.
One was something called "domain names." Instead entering the website name over on the right site of your toolbar, there was another, larger text field on the left where you could enter it. Rather than searching a proprietary Google database running on vast farms of Magic 8-Balls, this arcane "address" field consulted an authoritative registry of "domain names", and would lead you to the right site every time. Sadly, it sometimes required you to enter up to 8 extra characters! This burden was too much for most users to shoulder, and this cumbersome feature has been abandoned.
Another thing you used to see in browsers was something called a "bookmark." Etymologists are still trying to determine where the term "bookmark" originated. They suspect it has something to do with paper with funny squiggles on it. Anyway, these bookmarks allowed users to create a button that would take them directly to the web site of interest. Of course, creating a bookmark was a tedious, intimidating process, sometimes requiring as many as two menu clicks—or worse yet, use of the Ctrl-key!
Ah, the wonders of the ancients.
The site could "personalize" itself by showing some personal information,
easy recognizable by the user, on every page.
There are plenty of ways to implement it. The obvious one:
under first visit, the site requires user to upload some avatar,
and adds user's id to the cookies. After that, every time the user browses
the site, the avatar is shown.
When I set up my online bank account, it asked me to choose from a selection of images. The image I chose is now shown to me every time I login. This assures me that I am on the right website.
EDIT: i just read the link about the BoA SiteKey, this is apparently the same thing (it sounded from the name like a challenge-response dongle)
I suppose the best answer would be a hardware device which required a code from the bank and the user and authenticated both. But any of these things assume that people are actually thinking about the problem, which of course they don't. This was going on before internet banking was common - I had a friend who had her wallet stolen back in the 90s, and theif phoned her pretending to be her bank and persuaded her to reveal her PIN...
When the user first visits the site and logs in, he can share some personal information (even something very trivial) that imposter sites couldn't possible know - high school mascot, first street lived on, etc.
If there's ever any question of site authenticity, the site could share this information back to the user.
Like on TV shows/movies with the evil twin. The good twin always wins trust by sharing a secret that only the person who's trying to figure out who the good twin is would know.
You cannot prevent phishing per-se but you can take several steps each of which do a little bit to mitigate the problem.
1) If you have something like site-key or a sign-in seal, please ensure that these cannot be iframed on a malicious website. Just javascript framebusting may not be enough as IE has security="restricted".
2) Be very consistent about how you ask for user credentials - serve the login form over SSL (not just post-back over SSL). Do not ask for login on several places or sites. Encourage third parties who want to work with user data stored on your site to use OAuth (instead of taking your user's password).
3) You should never ask for information via email (with or without link).
4) Have a security page where you talk about these issues.
5) Send notification on changes to registered phone, email, etc.
Apart from above, monitor user account activity - such as changes to contact information, security Q&A, access, etc (noting time, ip, and there are several subtle techniques).

Resources