I have hopefully released OpenGuides 0.66 to CPAN.
http://dev.openguides.org/browser/trunk/Changes?rev=1328
On Thu 12 Apr 2012, Bob Walker bob@randomness.org.uk wrote:
I have hopefully released OpenGuides 0.66 to CPAN.
Thank you, bob! I will update the openguides.org website today.
I think the Changes file that bob links to above gives a clear idea of the changes in this release, so I won't repeat that information here, but I thought people might be interested in what I plan to work on next.
My main priority is to fix the maps. OpenGuides core is using a very old version of the Google Maps API. My intention is to switch to Leaflet. Along with this, I will add more ways to visualise the data, for example on RGL you can view all pubs in a given locale, whereas in core OpenGuides you can only view "all pubs" or "all things in a locale".
Another thing I plan to do is add more (optional) JavaScript that will make it easier for people to get data into their guides, e.g. a button to populate the four image fields from a single Flickr page URL. I am learning jQuery, to this end!
Finally, I want to rub off some of the rough edges that I keep bumping up against, e.g. there is no reason for our search to be a POST - it should be a GET so people can actually link to search results. So if there is a particular small thing that's been bugging you, now is a good time to tell me.
In the long term I would like to fix the search properly, since it's incredibly inefficient, but this is a big job that I don't think I will have time for in the near future.
Is anyone else doing any OpenGuides hacking at the moment, or has plans to do so soon?
Kake
On 13 Apr 2012, at 10:01, Kake wrote:
Finally, I want to rub off some of the rough edges that I keep bumping up against, e.g. there is no reason for our search to be a POST - it should be a GET so people can actually link to search results. So if there is a particular small thing that's been bugging you, now is a good time to tell me.
Lack of an API. ;-) But that's not a "small thing". More practically, it would be good if someone took a look at the HTML/CSS from a mobile perspective - the current templates are very desktop-oriented, whereas I presume that actual use of OpenGuides sites is increasingly mobile. I hear the "responsive design" buzzword bandied around a lot these days...
http://en.wikipedia.org/wiki/Responsive_Web_Design
Actually, from a mobile perspective, support for the W3C Geolocation API to allow me to search for stuff near where I am would be *hugely* helpful.
http://en.wikipedia.org/wiki/W3C_Geolocation_API
HTH,
S
On 17/04/2012 18:11, Stephen Jolly wrote:
Actually, from a mobile perspective, support for the W3C Geolocation API to allow me to search for stuff near where I am would be *hugely* helpful.
I wrote a thingy for that, but it's a patch to a non-standard search page for RGL and not a patch to Openguides itself. If anyone wants to port it to Openguides proper, then please feel free to take it: http://www.cantrell.org.uk/david/private/index.html
as written, I don't think it needs any server-side magic at all, as it's all client-side Javascript. Only tested on my iPhone, because that's the only place I care that it works :-)
On Tue, 17 Apr 2012, David Cantrell wrote:
On 17/04/2012 18:11, Stephen Jolly wrote:
Actually, from a mobile perspective, support for the W3C Geolocation API to allow me to search for stuff near where I am would be *hugely* helpful.
I wrote a thingy for that, but it's a patch to a non-standard search page for RGL and not a patch to Openguides itself. If anyone wants to port it to Openguides proper, then please feel free to take it: http://www.cantrell.org.uk/david/private/index.html
as written, I don't think it needs any server-side magic at all, as it's all client-side Javascript. Only tested on my iPhone, because that's the only place I care that it works :-)
Added as http://dev.openguides.org/ticket/286
On Tue, 17 Apr 2012, Stephen Jolly wrote:
On 13 Apr 2012, at 10:01, Kake wrote:
Finally, I want to rub off some of the rough edges that I keep bumping up against, e.g. there is no reason for our search to be a POST - it should be a GET so people can actually link to search results. So if there is a particular small thing that's been bugging you, now is a good time to tell me.
Lack of an API. ;-) But that's not a "small thing".
what do you mean by api? lots of data is availale as rdf and json.
On Tue 17 Apr 2012, Bob Walker bob@randomness.org.uk wrote:
lots of data is availale as rdf and json.
Speaking of which, I noticed that there seems to be a template missing from the distribution - json_index.tt, which is referenced in the show_index() method of OpenGuides.pm. This shows up as an error in live sites, e.g. http://oxford.openguides.org/wiki/?action=index;index_type=category;index_va...
Does anyone happen to have a copy of this template?
Kake
On 17 Apr 2012, at 23:50, Bob Walker wrote:
On Tue, 17 Apr 2012, Stephen Jolly wrote:
On 13 Apr 2012, at 10:01, Kake wrote:
Finally, I want to rub off some of the rough edges that I keep bumping up against, e.g. there is no reason for our search to be a POST - it should be a GET so people can actually link to search results. So if there is a particular small thing that's been bugging you, now is a good time to tell me.
Lack of an API. ;-) But that's not a "small thing".
what do you mean by api? lots of data is availale as rdf and json.
Is there a convenient way to find out what data is already available in explicitly machine-readable forms? I'd be happy to take a look and see if I can make some more specific suggestions.
S
On Fri, 20 Apr 2012, Stephen Jolly wrote:
On 17 Apr 2012, at 23:50, Bob Walker wrote:
On Tue, 17 Apr 2012, Stephen Jolly wrote:
On 13 Apr 2012, at 10:01, Kake wrote:
Finally, I want to rub off some of the rough edges that I keep bumping up against, e.g. there is no reason for our search to be a POST - it should be a GET so people can actually link to search results. So if there is a particular small thing that's been bugging you, now is a good time to tell me.
Lack of an API. ;-) But that's not a "small thing".
what do you mean by api? lots of data is availale as rdf and json.
Is there a convenient way to find out what data is already available in explicitly machine-readable forms? I'd be happy to take a look and see if I can make some more specific suggestions.
pages with rdf will have links to it.
http://london.randomness.org.uk/wiki.cgi?Cafe_East,_SE16_7LH http://london.randomness.org.uk/wiki.cgi?id=Cafe_East%2C_SE16_7LH;format=rdf rgl doesnt link to the json but you just change the format. http://london.randomness.org.uk/wiki.cgi?id=Cafe_East%2C_SE16_7LH;format=jso... these 2 tickets are currently relevant. http://dev.openguides.org/ticket/290 and http://dev.openguides.org/ticket/289
kake has been adding better json to some of locale and cateogry pages. i think.
S
On 20 Apr 2012, at 12:01, Bob Walker wrote:
On Fri, 20 Apr 2012, Stephen Jolly wrote:
On 17 Apr 2012, at 23:50, Bob Walker wrote:
On Tue, 17 Apr 2012, Stephen Jolly wrote:
On 13 Apr 2012, at 10:01, Kake wrote:
Finally, I want to rub off some of the rough edges that I keep bumping up against, e.g. there is no reason for our search to be a POST - it should be a GET so people can actually link to search results. So if there is a particular small thing that's been bugging you, now is a good time to tell me.
Lack of an API. ;-) But that's not a "small thing".
what do you mean by api? lots of data is availale as rdf and json.
Is there a convenient way to find out what data is already available in explicitly machine-readable forms? I'd be happy to take a look and see if I can make some more specific suggestions.
pages with rdf will have links to it.
http://london.randomness.org.uk/wiki.cgi?Cafe_East,_SE16_7LH http://london.randomness.org.uk/wiki.cgi?id=Cafe_East%2C_SE16_7LH;format=rdf rgl doesnt link to the json but you just change the format. http://london.randomness.org.uk/wiki.cgi?id=Cafe_East%2C_SE16_7LH;format=jso... these 2 tickets are currently relevant. http://dev.openguides.org/ticket/290 and http://dev.openguides.org/ticket/289
kake has been adding better json to some of locale and cateogry pages. i think.
The JSON representations (which I was previously unaware of) look like a very useful step in the direction I was thinking of. To answer your original question, my ideal API would have all the features necessary to create independent user interfaces to an OpenGuide (a native mobile application, perhaps), or to incorporate queries to an OpenGuide into other websites. Readily-parsable, stable representations of the node pages is a big part of it, and similar representations of the global category and locale lists would also be useful. The other obvious and significant missing piece would be JSON (or similar) representations of search results - http://london.randomness.org.uk/search.cgi?action=search&search=fish;for... currently throws a 500, for example, which is arguably a bug all by itself... A standard way to update node contents and metadata would also be needed, although arguably the existing form submission system could be used. A JSON representation of the "recent changes" page would be an additional convenience, as would be one for the user preferences page.
A good API would also fulfil some non-functional requirements - primarily good design (simplicity, consistency, principle of least surprise, etc - eg adding ;format=json to a request should return a JSON representation wherever reasonable, and fail gracefully otherwise), and good documentation.
Is that helpful? Feel free to disagree with any or all of it. :-) At the end of the day, the difference between a web API and a website with machine-readable data representations isn't necessarily huge, particularly if the URL structure is already sane - it's more about thinking of the way that a developer would want to be able to interact with the server as well as thinking about how a user would want it to behave.
Oh, and a specific useful addition to the JSON representation of node content would be the image details (where available).
S
On Fri 20 Apr 2012, Stephen Jolly steve@jollys.org wrote:
Readily-parsable, stable representations of the node pages is a big part of it, and similar representations of the global category and locale lists would also be useful.
bob has a ticket open for adding the node content to the JSON output of individual nodes - I will probably implement that at some point, though I think it actually needs to be done in Wiki::Toolkit rather than OpenGuides.
JSON output of the global category and locale lists is implemented in svn, with URLs of the form: http://127.0.0.1/~kake/og/wiki.cgi?action=index;cat=category;format=json http://127.0.0.1/~kake/og/wiki.cgi?action=index;cat=locales;format=json
The other obvious and significant missing piece would be JSON (or similar) representations of search results - http://london.randomness.org.uk/search.cgi?action=search&search=fish;for... currently throws a 500, for example, which is arguably a bug all by itself...
I think the OpenGuides search needs to be entirely rewritten from scratch. I wonder if we should have some form of hackfest to make this happen? Bob and I could host it (in Croydon).
A standard way to update node contents and metadata would also be needed, although arguably the existing form submission system could be used.
I do quite a lot of auto-updating/importing on OpenGuides sites - I use WWW::Mechanize for this.
A JSON representation of the "recent changes" page would be an additional convenience, as would be one for the user preferences page.
Agreed - can you open a couple of tickets for these?
Is that helpful?
It is very helpful, thank you! Do you know when you might be able to start sharing more details of the things you want to do with all this?
Oh, and a specific useful addition to the JSON representation of node content would be the image details (where available).
Can you add that to bob's ticket, or open a new one?
Kake
On 27 Apr 2012, at 11:29, Kake wrote:
A standard way to update node contents and metadata would also be needed, although arguably the existing form submission system could be used.
I do quite a lot of auto-updating/importing on OpenGuides sites - I use WWW::Mechanize for this.
Yes… scripting use cases are IMO slightly different because there's generally a programmer (and usually *the* programmer) on hand to fix them up if the details of the form being auto-submitted have changed.
A JSON representation of the "recent changes" page would be an additional convenience, as would be one for the user preferences page.
Agreed - can you open a couple of tickets for these?
Oh, and a specific useful addition to the JSON representation of node content would be the image details (where available).
Can you add that to bob's ticket, or open a new one?
Done.
Do you know when you might be able to start sharing more details of the things you want to do with all this?
A good question, tactfully phrased. :-) Whenever I use an OpenGuide (and that's generally RGL right now) from a smartphone (which is the usual way I access it), I think "this is a faff" and start designing an elegant native application interface in my head. So far, it has not made it out of my head and into reality. That's partly because, at present, it seems that writing such an application would involve (a) learning an awful lot about the source code on which OpenGuides are built and (b) taking on an unknown commitment to updating the application whenever someone makes an internally-consistent tweak to an apparently-unimportant feature of the code (like changing an HTTP POST to a GET, or modifying a URL). I've been in a position previously of trying to maintain a native application that's pretending that a web site can be treated like an API, and it wasn't a lot of fun (although in that case, there was a lot more screen scraping than would be the case for an OpenGuide app, even with the code as it is today).
Full disclosure though: although I believe that all of the suggestions I've made would make OpenGuides that implemented them subjectively better (for my example use case and for others), I don't look at my life and see an app-development-shaped hole in it this summer. So take that into account in any prioritisation of enhancements.
S
On Fri 27 Apr 2012, Stephen Jolly steve@jollys.org wrote:
Whenever I use an OpenGuide (and that's generally RGL right now) from a smartphone (which is the usual way I access it), I think "this is a faff" and start designing an elegant native application interface in my head.
It strikes me that perhaps in the absence of a native application, it might be better to bend our efforts towards (as you've alluded to before) a more responsive design that works more smoothly on mobile devices. I feel that the main reason for wanting an app over a website is when there's a significant amount of stuff you can do without communicating with the remote server.
For _updating_ an OpenGuide, I can definitely see a use for being able to enter all the data and then tell your phone to send it when it next has an internet connection - a good reason to have an app. But for accessing the data already in an OpenGuide while out and about, would a significantly more usable website solve most of the problem?
Kake
On Sat, Apr 28, 2012 at 11:07:18AM +0100, Kake wrote:
On Fri 27 Apr 2012, Stephen Jolly steve@jollys.org wrote:
Whenever I use an OpenGuide (and that's generally RGL right now) from a smartphone (which is the usual way I access it), I think "this is a faff" and start designing an elegant native application interface in my head.
It strikes me that perhaps in the absence of a native application, it might be better to bend our efforts towards (as you've alluded to before) a more responsive design that works more smoothly on mobile devices. I feel that the main reason for wanting an app over a website is when there's a significant amount of stuff you can do without communicating with the remote server.
For _updating_ an OpenGuide, I can definitely see a use for being able to enter all the data and then tell your phone to send it when it next has an internet connection - a good reason to have an app. But for accessing the data already in an OpenGuide while out and about, would a significantly more usable website solve most of the problem?
You've mentioned that offline editing would be useful, but why aspire towards offline browinsg too? That would presumably need a way of interrogating changes in a global edit timeline to update efficiently a local cache.
One of the main problems I foresee with native applications is the nonstandard wiki markup (feel free to tell me that I'm wrong and that the wiki markup is in fact interpreted by many standard libraries - I'm not particularly up-to-date in this area) so I wonder whether some improvements might be needed in that area.
On Sat 28 Apr 2012, Dominic Hargreaves dom@earth.li wrote:
One of the main problems I foresee with native applications is the nonstandard wiki markup (feel free to tell me that I'm wrong and that the wiki markup is in fact interpreted by many standard libraries - I'm not particularly up-to-date in this area) so I wonder whether some improvements might be needed in that area.
An API could easily offer rendered HTML as well as raw wiki markup, if that's a problem.
Kake
On 28 Apr 2012, at 11:07, Kake wrote:
It strikes me that perhaps in the absence of a native application, it might be better to bend our efforts towards (as you've alluded to before) a more responsive design that works more smoothly on mobile devices. I feel that the main reason for wanting an app over a website is when there's a significant amount of stuff you can do without communicating with the remote server.
For _updating_ an OpenGuide, I can definitely see a use for being able to enter all the data and then tell your phone to send it when it next has an internet connection - a good reason to have an app. But for accessing the data already in an OpenGuide while out and about, would a significantly more usable website solve most of the problem?
I suspect it would solve a lot of the problem - but web design is not my strong point, so it's hard to say for sure. :-)
(Not that I'm claiming that native application design *is* my strong point…)
S
On Fri 20 Apr 2012, Bob Walker bob@randomness.org.uk wrote:
pages with rdf will have links to it.
http://london.randomness.org.uk/wiki.cgi?Cafe_East,_SE16_7LH http://london.randomness.org.uk/wiki.cgi?id=Cafe_East%2C_SE16_7LH;format=rdf rgl doesnt link to the json but you just change the format. http://london.randomness.org.uk/wiki.cgi?id=Cafe_East%2C_SE16_7LH;format=jso...
RGL does link to the JSON now! This was an oversight which I have corrected.
Incidentally, in core OpenGuides the header.tt includes links like this:
<link rel="alternate" type="application/rss+xml" title="Page as RSS" href="[% feed_base %];format=rss" /> <link rel="alternate" type="application/atom+xml" title="Page as Atom" href="[% feed_base %];format=atom" />
Should there be one for the JSON version too, or is that not what this type of link is for? And if there should be one, what should the "type" attribute be?
kake has been adding better json to some of locale and cateogry pages. i think.
Sort of. I fixed ?action=index;format=json to actually work, _but_ the JSON links on locale and category pages actually link to e.g. ?id=My_Category;format=json which is like the JSON output for a normal page.
Kake
On Tue 17 Apr 2012, Stephen Jolly steve@jollys.org wrote:
More practically, it would be good if someone took a look at the HTML/CSS from a mobile perspective - the current templates are very desktop-oriented, whereas I presume that actual use of OpenGuides sites is increasingly mobile.
This isn't a small thing either, so ticket created at http://dev.openguides.org/ticket/287 - thanks!
Kake
openguides-dev@lists.openguides.org
-
Bob Walker -
David Cantrell -
Dominic Hargreaves -
Kake -
Stephen Jolly