If you have no interest in seeing "old tweets" then pass the parameter that
indicates that you want to strictly see the most recent tweets (the legacy
behavior). You get what you want and those who are interested in more signal
amongst the ever increasing noise can find out the
moderately-less-recent-but-most-popular results associated with their search
term. You represent one desired use case. There are others. We are providing
a mechanism to get one,  the other or both. Choose whichever you like.

On Tue, Apr 6, 2010 at 6:11 AM, Dewald Pretorius <dpr...@gmail.com> wrote:

> Raffi,
>
> "We obviously feel that users want the most relevant tweets first."
> Has this been determined and confirmed with user focus groups, or is
> this just an opinion that originated somewhere in a Twitter office or
> meeting room?
>
> I am one of those users, and I have just told you that I have no
> interest in seeing old tweets, regardless of how "popular" or
> "relevant" they deem to be by your algorithms. When I search Twitter
> (and I'm making this statement as a user of search.twitter.com, not as
> an API consumer) I want to see in real-time what is happening right
> now. That is why I am using search.twitter.com and not google.com for
> that purpose. If you're going to rather show "relevant" tweets, then I
> will instead use Google because their matching algorithms are far more
> advanced and mature.
>
> On Apr 6, 9:47 am, Raffi Krikorian <ra...@twitter.com> wrote:
> > hi dewald.
> >
> > we obviously feel that users want the most relevant tweets first (the
> > use of "popular" is unfortunate here). and the web interface of
> search.twitter.com
> >   has begun an evolution in that direction.
> >
> > it's still unclear what Twitter is going to do with the API (hence the
> > silence), however, to go with your argument: "time indexed" search is,
> > potentially, something a third party service could do.  we do provide
> > the streaming API to get much-better-than-search-real-time results.
> >
> > On Apr 6, 2010, at 4:28 AM, Dewald Pretorius <dpr...@gmail.com> wrote:
> >
> >
> >
> > > Raffi,
> >
> > > Tweet id is a no-brainer. We understand that an linear incrementing
> > > number does not scale because at some point it must cycle back to 1.
> >
> > > Search is a different animal.
> >
> > > When I do a Twitter search, I expect your system to tell me what is
> > > *happening* right now. I am NOT expecting your system to tell me what
> > > is *popular* right now.
> >
> > > This popular tweet thing is diluting and violating your entire mission
> > > of "real-time".
> >
> > > If I search for "earthquake" I want to see what is *happening* in
> > > real-
> > > time. I have no interest in seeing a 30-minute old tweet from @aplusk
> > > or @ev just because they are trusted accounts and the tweet is being
> > > retweeted a lot (to simplify the popularity algorithm).
> >
> > > If people have a need to see popular tweets, you know what? That is an
> > > ideal service to be provided by a third-party developer/service.
> >
> > > Twitter is real-time, and has defined real-time information. Stick to
> > > it. Don't dilute your mission.
> >
> > > On Apr 6, 1:03 am, Raffi Krikorian <ra...@twitter.com> wrote:
> > >> we have the developer advocate we want, but, of course, please feel
> > >> free to
> > >> reach out to taylor with your concerns and what you would like him
> > >> to do to
> > >> help you all out.  i'm sure he would welcome the help.
> >
> > >> as for what's going on behind the scenes, i'll describe it out as so:
> >
> > >>    - tweet ID generation - this is a pure scalability problem that
> > >> lays at
> > >>    the heart of twitter being able to grow.  unless i'm mistaken,
> > >> in the end, a
> > >>    centralized way of generating tweet IDs that are strictly
> > >> increasing by one
> > >>    does not scale.  the method that we generate tweet IDs, and
> > >> therefore the
> > >>    IDs themselves, will, almost probably, have to change.
> > >>    - popular tweets in search - twitter is increasingly being
> > >> relied upon to
> > >>    be the place for relevant real-time information.  most end-users
> > >> would say
> > >>    that a time indexed search stream is not as valuable.  as you
> > >> all can
> > >>    probably tell, keeping a real time search index operational is
> > >> hard enough,
> > >>    but imagine keeping a service running that is simultaneously
> > >> delivering
> > >>    relevant results along with time indexed results.  that's
> > >> significantly
> > >>    harder.
> >
> > >> those are the issues facing us.  as i said, please bear with us --
> > >> once we
> > >> have weighed all these issues internally, we will of course, let
> > >> everybody
> > >> know.  we've heard the concerns, but, if there are new ones, please
> > >> let us
> > >> know!
> >
> > >> On Mon, Apr 5, 2010 at 8:28 PM, Orian Marx (@orian)
> > >> <or...@orianmarx.com>wrote:
> >
> > >>> Raffi, one of the things that really stands out for me in what you
> > >>> are
> > >>> saying here is that there are lots of "moving pieces" that the
> > >>> team is
> > >>> trying to "align quickly". The question is, who and what is
> > >>> dictating
> > >>> the schedule? I get the sense that all the recent changes are
> > >>> parts of
> > >>> a bigger picture plan for Twitter, but the reality is that Twitter
> > >>> HQ
> > >>> has not conveyed a real sense of this bigger picture to the
> > >>> developer
> > >>> community - and it certainly hasn't conveyed why these recent
> > >>> changes
> > >>> need to "align quickly". So inevitably the situation at hand seems
> > >>> to
> > >>> be that some serious developer concerns effectively need to be
> > >>> pushed
> > >>> aside in order to meet some internal goals of Twitter that have not
> > >>> been made public. I can understand that as a choice that Twitter
> > >>> management might make. What I think would be unreasonable would be
> > >>> for
> > >>> Twitter to expect the developer community to not push back.
> >
> > >>> I think it's pretty clear that the "developer advocate" concept
> > >>> needs
> > >>> to be fleshed out more, and i'll try to push for that at Chirp. If
> > >>> anyone else is interested in helping make that discussion
> > >>> productive,
> > >>> lets get started :-)
> >
> > >>> On Apr 5, 8:45 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> > >>>> to clarify (from my personal view), what taylor has provided to
> > >>>> the team
> > >>> is
> > >>>> a clear view into what developers want / think / feel --
> > >>>> basically, a
> > >>> pulse
> > >>>> on the developer community.  he's doing a fine job.  and for these
> > >>>> particular issues, not only has he conveyed the feelings of our
> > >>> community,
> > >>>> but everybody on the team has also heard it personally.  i hope
> > >>>> we have
> > >>> more
> > >>>> to say about both these topics soon.  as you can all imagine,
> > >>>> there is a
> > >>>> myriad of moving pieces that we are all trying to get to align
> > >>>> quickly --
> > >>>> there are technical issues, there are the concerns of our
> > >>>> developer and
> > >>> user
> > >>>> community, and then, of course, there are the overall objectives of
> > >>> Twitter,
> > >>>> Inc.  getting them all to align is, at times, ridiculously
> > >>>> difficult.
> >
> > >>>> On Mon, Apr 5, 2010 at 5:01 PM, Dewald Pretorius <dpr...@gmail.com>
> > >>> wrote:
> > >>>>> To be fair to Taylor, we may be expecting too much from his role.
> >
> > >>>>> When reading the job description of a Twitter Developer Advocate
> > >>>>> [1],
> > >>>>> the only traditional advocate responsibility listed there is
> > >>>>> "Represent developer needs when planning new API features and
> > >>>>> changes."
> >
> > >>>>> Now, if Taylor conveyed our objections to the Platform team,
> > >>>>> then he
> > >>>>> adequately executed that responsibility. I'm sure he did.
> >
> > >>>>> The rest of the responsibilities all speak in a Twitter to
> > >>>>> Developer
> > >>>>> direction, i.e., more a Communicator than an Advocate.
> >
> > >>>>> In particular, in the About This Job section, it says, "it is
> > >>>>> necessary to have an official voice regularly communicating with
> > >>>>> the
> > >>>>> community," which underlines Communicator instead of Advocate.
> >
> > >>>>> [1]http://dld.bz/7Z
> >
> > >>>>> On Apr 4, 9:39 pm, funkatron <funkat...@gmail.com> wrote:
> > >>>>>> Taylor,
> >
> > >>>>>> I'm about to vent. Sorry about this.
> >
> > >>>>>> At some point did you plan on addressing any of the numerous
> > >>>>>> complaints raised against making this anything other than opt-in?
> >
> > >>>>>> Several of us raised this, and you offered no response for 10
> > >>>>>> days.
> > >>>>>> See <http://groups.google.com/group/twitter-development-talk/
> > >>>>>> browse_thread/thread/983086ae9935d50c/d4a8e0fbc0fee5c0?
> > >>>>>> lnk=gst&q=popular+search#d4a8e0fbc0fee5c0>
> >
> > >>>>>> When you *did* post, you didn't actually address any concerns,
> > >>>>>> or say
> > >>>>>> "hey, I spoke with the API team. This is why it's going like
> > >>>>>> this."
> > >>>>>> Like, say, an advocate of 3rd party developers would do.
> >
> > >>>>>> I'm not doing Twitter any favors; I realize that. I'm just the
> > >>>>>> developer of a tiny, old open source client whose been hacking
> > >>>>>> away
> > >>> on
> > >>>>>> the API since spring of 2007. I'm not a strategic partner, and I
> > >>> don't
> > >>>>>> bring Twitter any value. No VC funding will be coming my way, I'm
> > >>>>>> afraid, and it doesn't make headlines on TechCrunch when I add
> > >>>>>> a new
> > >>>>>> feature (ping.fm? I supported that in 2007).
> >
> > >>>>>> But what I would like is to be treated with some respect. If
> > >>>>>> you post
> > >>>>>> something, and get significant pushback, I'd expect at *very*
> > >>>>>> least
> > >>>>>> some explanation about why doing it the way you guys want to do
> > >>>>>> it is
> > >>>>>> a great idea. If you are an advocate for 3rd party developers,
> > >>>>>> as I
> > >>>>>> interpreted your title, then doing us the courtesy of not simply
> > >>>>>> ignoring/avoiding the concerns we voice seems like part of your
> > >>>>>> job.
> >
> > >>>>>> It seems like you're doing a lot of selling of changes to *us*.
> > >>> That's
> > >>>>>> not an advocate -- that's an evangelist. If your role there is an
> > >>>>>> evangelist, then fine. You're doing a good job of ignoring the
> > >>> tougher
> > >>>>>> questions and sticking to company lines.
> >
> > >>>>>> The point here is that I used to cut the API crew a lot of slack
> > >>>>>> because I thought they at least weren't feeding us a line. I felt
> > >>> they
> > >>>>>> actually were aiming for transparency, but were just overworked.
> >
> > >>>>>> If this is the way things are gonna go with someone who is,
> > >>>>>> presumably, tasked with being *our* advocate, I think Twitter is
> > >>>>>> losing the thread. Maybe it doesn't matter for you guys
> > >>>>>> financially,
> > >>>>>> and you'll go on and do Very Important Things and lots of
> > >>>>>> people will
> > >>>>>> continue to view Twitter as Game-Changing Technology, but it
> > >>>>>> sure is
> > >>> a
> > >>>>>> bummer for me.
> >
> > >>>>>> --
> > >>>>>> Ed Finklerhttp://funkatron.com
> > >>>>>> @funkatron
> > >>>>>> AIM: funka7ron / ICQ: 3922133 / 
> > >>>>>> XMPP:funkat...@gmail.com<xmpp%3afunkat...@gmail.com>
> <XMPP
> > >>>>>> %3afunkat...@gmail.com>
> > >>> <xmpp%3afunkat...@gmail.com <xmpp%253afunkat...@gmail.com> <
> xmpp%253afunkat...@gmail.com <xmpp%25253afunkat...@gmail.com>>>
> >
> > >>>>>> On Apr 1, 8:53 pm, Taylor Singletary
> > >>>>>> <taylorsinglet...@twitter.com>
> > >>>>>> wrote:
> >
> > >>>>>>> Hi Folks,
> >
> > >>>>>>> As indicated a few weeks ago, we're launching our new *beta*
> > >>>>> enhancements to
> > >>>>>>> search.twitter.com and the Search API today -- it's currently
> > >>> rolling
> > >>>>> out to
> > >>>>>>> our servers. Thank you all for your feedback.
> >
> > >>>>>>> *Key API Takeaways*:
> >
> > >>>>>>>   - During the current phase, receiving "popular tweets" in your
> > >>> API
> > >>>>> search
> > >>>>>>> results is *OPT-IN*. You will not see the new top results in
> > >>>>>>> search
> > >>>>>  unless
> > >>>>>>> you specify the *result_typ**e* parameter on your search query
> > >>> string.
> >
> > >>>>>>>   - The result_type parameter takes one of
> >
> > ...
> >
> > read more ยป- Hide quoted text -
> >
> > - Show quoted text -
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>



-- 
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio

Reply via email to