Re: [twitter-dev] dev.twitter.com usability - FAIL
I miss the RSS feeds. -- Little androids dreaming of Nexus Ones compiled this text. On Apr 28, 2010 7:27 AM, "Nigel Legg" wrote: Personally thought the new pages were a vast improvement on the old ones in terms of finding what I need. Usability is in the way the user thinks, I suppose. On 28 April 2010 15:11, Josh Roesslein wrote: > > Yeah one improvement may b...
Re: [twitter-dev] dev.twitter.com usability - FAIL
Personally thought the new pages were a vast improvement on the old ones in terms of finding what I need. Usability is in the way the user thinks, I suppose. On 28 April 2010 15:11, Josh Roesslein wrote: > Yeah one improvement may be to place the API "hurl" tool into each API > documentation page > with all parameter pre-filled so it is ready to be experiment with to see > how the responses look. > This also helps avoid out of date info if the responses should change. > > Josh > > > On Tue, Apr 27, 2010 at 4:21 PM, Taylor Singletary < > taylorsinglet...@twitter.com> wrote: > >> Thanks for the feedback, Jonathon. We're working to address all these pain >> points on an ongoing basis. >> >> Taylor Singletary >> Developer Advocate, Twitter >> http://twitter.com/episod >> >> >> On Tue, Apr 27, 2010 at 2:17 PM, Jonathon Hill wrote: >> >>> The new dev.twitter.com website that launched at Chirp a few weeks ago >>> is very nice and attractive but there are several major usability >>> issues: >>> >>> * The new API documentation does not provide return values of the API >>> calls. The old wiki provided this information, along with usage notes >>> that are not present either on the new site. >>> >>> * It is difficult to look up API endpoints required for a given type >>> of functionality. If you don't remember the exact endpoint to look >>> for, it can be frustrating trying to find the right one. This would >>> easily be fixed using a more descriptive list of endpoints, and/or >>> more visual contrast between headings and list items. >>> >>> * I tend to overlook the endpoint description in the blue header >>> section. My eyes expect it in the white area below. Please move it, >>> and make it stand out more. >>> >>> * The Supported formats, Supported request methods, Requires >>> Authentication, and Rate Limited sections use up an awful lot of >>> vertical space on the page unnecessarily. Making each one of these a >>> heading also dilutes the visual hierarchy on the page and takes away >>> from more detailed and important information on the page, from a >>> reference standpoint. I think these would be more effectively >>> presented as a list under a "Metadata" heading, or as a small table. >>> >>> * The API console is very restricted without login and registration of >>> an app. I think this is a mistake. Login should be required only for >>> those calls that require authentication. >>> >>> * The API console would be much easier to use if there were parameter >>> hints for each call on the page somewhere. Prepopulating the parameter >>> list would be awesome! >>> >>> These are all things that have been kindof in my face as I've tried to >>> use dev.twitter.com in my day to day development work. I would be >>> delighted if you would address these issues. >>> >>> Thanks! >>> >>> Jonathon Hill >>> Company52 >>> http://company52.com >>> @compwright >>> >> >> >
Re: [twitter-dev] dev.twitter.com usability - FAIL
Yeah one improvement may be to place the API "hurl" tool into each API documentation page with all parameter pre-filled so it is ready to be experiment with to see how the responses look. This also helps avoid out of date info if the responses should change. Josh On Tue, Apr 27, 2010 at 4:21 PM, Taylor Singletary < taylorsinglet...@twitter.com> wrote: > Thanks for the feedback, Jonathon. We're working to address all these pain > points on an ongoing basis. > > Taylor Singletary > Developer Advocate, Twitter > http://twitter.com/episod > > > On Tue, Apr 27, 2010 at 2:17 PM, Jonathon Hill wrote: > >> The new dev.twitter.com website that launched at Chirp a few weeks ago >> is very nice and attractive but there are several major usability >> issues: >> >> * The new API documentation does not provide return values of the API >> calls. The old wiki provided this information, along with usage notes >> that are not present either on the new site. >> >> * It is difficult to look up API endpoints required for a given type >> of functionality. If you don't remember the exact endpoint to look >> for, it can be frustrating trying to find the right one. This would >> easily be fixed using a more descriptive list of endpoints, and/or >> more visual contrast between headings and list items. >> >> * I tend to overlook the endpoint description in the blue header >> section. My eyes expect it in the white area below. Please move it, >> and make it stand out more. >> >> * The Supported formats, Supported request methods, Requires >> Authentication, and Rate Limited sections use up an awful lot of >> vertical space on the page unnecessarily. Making each one of these a >> heading also dilutes the visual hierarchy on the page and takes away >> from more detailed and important information on the page, from a >> reference standpoint. I think these would be more effectively >> presented as a list under a "Metadata" heading, or as a small table. >> >> * The API console is very restricted without login and registration of >> an app. I think this is a mistake. Login should be required only for >> those calls that require authentication. >> >> * The API console would be much easier to use if there were parameter >> hints for each call on the page somewhere. Prepopulating the parameter >> list would be awesome! >> >> These are all things that have been kindof in my face as I've tried to >> use dev.twitter.com in my day to day development work. I would be >> delighted if you would address these issues. >> >> Thanks! >> >> Jonathon Hill >> Company52 >> http://company52.com >> @compwright >> > >
Re: [twitter-dev] dev.twitter.com usability - FAIL
Thanks for the feedback, Jonathon. We're working to address all these pain points on an ongoing basis. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Tue, Apr 27, 2010 at 2:17 PM, Jonathon Hill wrote: > The new dev.twitter.com website that launched at Chirp a few weeks ago > is very nice and attractive but there are several major usability > issues: > > * The new API documentation does not provide return values of the API > calls. The old wiki provided this information, along with usage notes > that are not present either on the new site. > > * It is difficult to look up API endpoints required for a given type > of functionality. If you don't remember the exact endpoint to look > for, it can be frustrating trying to find the right one. This would > easily be fixed using a more descriptive list of endpoints, and/or > more visual contrast between headings and list items. > > * I tend to overlook the endpoint description in the blue header > section. My eyes expect it in the white area below. Please move it, > and make it stand out more. > > * The Supported formats, Supported request methods, Requires > Authentication, and Rate Limited sections use up an awful lot of > vertical space on the page unnecessarily. Making each one of these a > heading also dilutes the visual hierarchy on the page and takes away > from more detailed and important information on the page, from a > reference standpoint. I think these would be more effectively > presented as a list under a "Metadata" heading, or as a small table. > > * The API console is very restricted without login and registration of > an app. I think this is a mistake. Login should be required only for > those calls that require authentication. > > * The API console would be much easier to use if there were parameter > hints for each call on the page somewhere. Prepopulating the parameter > list would be awesome! > > These are all things that have been kindof in my face as I've tried to > use dev.twitter.com in my day to day development work. I would be > delighted if you would address these issues. > > Thanks! > > Jonathon Hill > Company52 > http://company52.com > @compwright >
[twitter-dev] dev.twitter.com usability - FAIL
The new dev.twitter.com website that launched at Chirp a few weeks ago is very nice and attractive but there are several major usability issues: * The new API documentation does not provide return values of the API calls. The old wiki provided this information, along with usage notes that are not present either on the new site. * It is difficult to look up API endpoints required for a given type of functionality. If you don't remember the exact endpoint to look for, it can be frustrating trying to find the right one. This would easily be fixed using a more descriptive list of endpoints, and/or more visual contrast between headings and list items. * I tend to overlook the endpoint description in the blue header section. My eyes expect it in the white area below. Please move it, and make it stand out more. * The Supported formats, Supported request methods, Requires Authentication, and Rate Limited sections use up an awful lot of vertical space on the page unnecessarily. Making each one of these a heading also dilutes the visual hierarchy on the page and takes away from more detailed and important information on the page, from a reference standpoint. I think these would be more effectively presented as a list under a "Metadata" heading, or as a small table. * The API console is very restricted without login and registration of an app. I think this is a mistake. Login should be required only for those calls that require authentication. * The API console would be much easier to use if there were parameter hints for each call on the page somewhere. Prepopulating the parameter list would be awesome! These are all things that have been kindof in my face as I've tried to use dev.twitter.com in my day to day development work. I would be delighted if you would address these issues. Thanks! Jonathon Hill Company52 http://company52.com @compwright
