Review my new site : 48ers - Realtime Social Search | Hacker News Reader

Review my new site : 48ers - Realtime Social Search

48ers.com

21 pointswhyleym17 comments

Hacker News is my favourite site on the internet and having been a member for almost 4 years I've learnt a lot from everyone here. My co-founders and I couldn't think of a better place to launch our new site and get valuable feedback from a group of people we respect.

48ers allows realtime searching of a number of social networks - we created the site to scratch our own itch - to track what people are saying about other websites we own. We hope it might be useful for brands too.

Feel free to give it a go at http://www.48ers.com or jump straight into a search:

http://48ers.com/search/?q=hacker+news

http://48ers.com/search/?q=airbnb

http://48ers.com/search/?q=balsamiq

http://48ers.com/search/?q=mark+zuckerberg

Please comment here and tell us about:

* What you like

* What you dislike

* Any bugs you find

* Where you'd like to see this go in future (we have some ideas but would love to hear yours)

I'm working on something similar with www.unscatter.com, though you and I are taking different approaches on clutter vs providing more context.

Likes: - Layout and design. I wish I had a better knack for that kind of thing. 48ers is a lot of what I was going for and still haven't reached as for a minimalistic approach that's also appealing the to eye. - The "Getting results" javascript is a real nice usability touch. Nice enough that honestly, would you mind if I implemented something similar when I get back to working on my own site? I prefer not to blatantly steal :)

Suggestions: - It's a little slow. Not sure what your backend is, hopefully you're using something that allows you to submit all your requests at once and handle each as a callback. If you are, I would suggest benchmarking your requests to figure out which are your slowest ones and making sure you make those first. I shaved 10-30ms per uncached request by making my request to Facebook the first request I launched rather than the last, as it was the slowest API to respond.

- Are you caching results? I did a search for "Epic 4g" (as I want to know when it will be coming out) and then immediately hit search again and it took a bit for that next request to load. I would really suggest you cache at least the data (as I'm doing) if not the entire results page (as I will probably move to with nginx caching modules) for x seconds/minutes and it will save you bandwidth costs, especially for those trending topics which may get a lot of concurrent hits if you app ever scales to appreciable traffic.

Only question I really have is do you have a plan for advertising other than Adsense? Adsense is going to have a hard time matching ads for search result pages.

Thanks for taking time out to comment.

As you say Unscatter seems a similar idea and we can see where you're coming from re: context.

We hear you on the speed - this is what we are trying to focus on - make this a super quick, great user experience. You're right in that caching is the way to go - again it's one of those release early and iterate items. We don't presently do any caching as such so this is no doubt something we will iterate on.

In terms of monetisation - for the first few months we are looking at adsense to get a feel for how contextual the ads are and what the relative click through rates will be. After this we have some ideas that we hope will work out well.

Can you explain a bit more about how you actually get this data in real time? Are you scrapping these sites? Doing REST calls every x seconds. Or using the streaming API for twitter?

Are you storing any of this data persistently? Can I do historic searches on any term, or just something that was indexed before?

Are you planning on adding any sentiment analysis? Or any other analytics on the data, assuming you are storing it.

Do you have an API or plan to support an API down the road. What's your monetization plan?

Presently we are using the various API's that are available for each of the services that we are linking into. We have some custom code which interogates this data and renders it to the user. In respect of historic searches and storing of the data, storing data is not something we are doing from day 1, however this is something we are certainly looking longer term. In terms of historic searches - again day 1, we search back as long as the various API's allow.

Sentiment Analysis is something we looked at, however at the moment we wanted to keep things stripped back - that's not to say we may not offer this in future as an advanced search feature or even a feature that users can turn on/off.

API's are on the agenda and these are actively being developed to allow others to call into the service. In terms of monetisation we are starting out with a contextual ad model (using Google Adsense to start) - which obviously hasn't worked out too bad for Google, however longer term we have some other ideas around this.

I'm not sure what this does differently from every other search engine, or search engine aggregator?

Aggregating results via third party APIs is a neat, although old, stunt -- but doesn't exactly translate into a startup business to compete with search engines.

Our aim was to provide something that was uncluttered, simple and fast which (eventually) covers as many social network and real people's views of either what people are saying about your brand or whatever you wish to search on in realtime.

We ourselves use this daily as a tool to track what people are saying about our other web properties.

If I search for a hash tag I would prefer to only get stuff that actually has that hash tag in it. For example, searching for #mac return lots of tweets about mac and cheese, which isn't all that useful.

Yep - we agree - we'll have a look into this

Have you considered adding RSS feeds on the search result pages, or would this not fit in with your eventual business model? It would certainly make me use the service at any rate.

It's funny you should say that - this is a feature that is high on the to be developed list. We are trying to take the release, iterate often approach - so hopefully this feature will be in soon. Thanks for the comment - any other suggestions ?

I would refine the phrase "social search." To me, it means searching alongside other people with similar goals, rather than an all-in-one site for social media search.

It is our intention to be an all-in-one social media search. If 'social search' does not portray this have you any thoughts on what a good tagline would be to meet our aim - any suggestions more than welcome. Thanks

Can you enlighten me on how you plan to differentiate yourselves from the existing real-time search engines like collecta, oneriot, etc.?

Thanks for taking time out to comment.

Collecta albeit a good service we felt was a little cluttered and on occasion a little sluggish - our service's aim is to be decluttered, simple, fast social search. With regards OneRiot - they are more of a full featured offering where we intend to focus more on the core search function presented back to users in an uncluttered easy to read manner.

[Removed in the interest of responsible disclosure]

Thanks - we'll take a look into that

Reply on news.ycombinator.com