[p2pu-webcraft] Intermediate Webcraft Challenges

Tue Oct 18 00:55:51 UTC 2011

Mobile is definitely part of the web, but I think bluetooth might be a
stretch. I could see things like HTML5 local storage, geo detection, and
responsive styles fitting into the challenges very nicely. Looking forward
to seeing more detail on some of these.
--
contact info:
http://www.johndbritton.com
@johndbritton - http://twitter.com/johndbritton

On Tue, Oct 18, 2011 at 2:20 AM, Jessy Kate Schingler
<jessy at jessykate.com>wrote:

> this is awesome feedback john, thanks. you're totally right about the
> performance-analysis idea, it should be tightened up/clarified.
>
> love your suggestions for the other ones. great idea on extending the
> "impossibility" challenge
>
> your reaction to the bluetooth idea gave me pause actually. i realized that
> i had unconsciously collapsed web and mobile development in my mind. for a
> minute i thought, yeah he's right, they're different. and then i started to
> wonder...is it really outside scope? just some thoughts on that to maybe
> spur discussion: mobile is one of the front lines of web development in many
> ways right now. i know bluetooth might seem like a bit of a stretch compared
> to, say, a mobile website, or client app that mostly uses tcp/ip to interact
> with an API. on the other hand, these lower level interfaces are
> opportunities to extend the ways we interact with the content of the web,
> and with each other.
>
> anyway, i'm sure it;s not the first challenge i'll work on but just thought
> it was an interesting thing to discuss.
>
> as for moving forward, i'm planning to pick one of the challenges and hone
> in on developing it in more detail by using chloe's awesome "guides" .then
> i'll send the more detailed version around for feedback.
>
> feedback is still welcome if anyone else has any!
> jessy
>
>
>
> On Mon, Oct 17, 2011 at 9:06 AM, John Britton <john at p2pu.org> wrote:
>
>> * writing scrapers and parsers for large/messy unstructured data. for
>>> example, taking the plain text transcripts from a senate hearing and parsing
>>> it into a structured form that identifies and associated speakers with their
>>> spoken text, and possibly brings in other data about each speaker from a
>>> secondary source.
>>
>>
>> Sounds fun, I would encourage giving a few different content examples so
>> there is something for everyone.
>>
>> * examining an existing site/module/library, and identifying
>>> architectural, design, or deployment choices that are likely to result in a
>>> bottleneck/crash during scaling or high load. what component of the site in
>>> question would be the limiting factor? why? for example, would it be
>>> bandwidth? number of connections? database speed? a really inefficient loop?
>>> how could these expected bottlenecks/load issues be addressed?
>>
>>
>> I think this could be tightened up a bit, it's pretty open ended and if I
>> were to attempt it I'd like to have a clear goal. Maybe you could provide a
>> few different things to investigate and specific problems to look for, sort
>> of like a checklist.
>>
>> * design an API from scratch (either design-only or design and implement):
>>> for example, pick a site you think is cool, that has an API (but one that
>>> you are not familiar with). without looking at what they have done, write
>>> out a design for what you think the API should look like - what function
>>> calls and features would it support? what should the API calls look like?
>>> what format would the returned data be in? after you're done, compare with
>>> what the existing site has, and compare/contrast.
>>
>>
>> I really like this idea a lot. Perhaps encourage people to wrap existing
>> APIs and create a better interface for them. Writing an API client library
>> is a great way to get experience as well.
>>
>>  * identify 10 things that cannot be done on the web today. what are they,
>>> why are they not possible, what could be done to make them possible.
>>
>>
>> Love this one as well, I'd add a step that is to take a look at what
>> others think is impossible and explain how they are possible today.
>>
>> * an import/export tool-- for example, write an import tool that grabs all
>>> your tweets and imports them as wordpress posts. (this gets at the idea but
>>> would prefer to make it more useful). the idea would be to get at working
>>> with larger data, working with data you can't control, and having to work
>>> with/convert between interfaces that others have designed.
>>
>>
>> Agree that it should be something more useful, maybe start with a P2PU
>> dataset that we want converted into as many formats as possible. You can
>> earn a badge by moving this data to a new format.
>>
>> * write code/pseudocode for bluetooth pairing using the android API
>>
>>
>> This one doesn't seem to fit with webcraft, it's a bit beyond the scope of
>> the web in my opinion.
>>
>> * pick your favourite website. what browser standards is it compatible
>>> with? which ones is it NOT compatible with? are there simple changes you
>>> could make, to make it compliant?
>>
>>
>> Why did the developers choose to break the rules? Inexperience? Laziness?
>> or did they have a good reason?
>>
>> * pick a site you like that does not have a mobile version. grab a
>>> snapshot of their page and any necessary css and js files being used. then
>>> modify the design locally to produce a proper mobile version of the site.
>>
>>
>> I think hacking on other people's stuff is great and it illustrates how
>> keeping web standards open empowers anyone.
>> --
>> contact info:
>> http://www.johndbritton.com
>> @johndbritton - http://twitter.com/johndbritton
>>
>>
>>
>> On Wed, Oct 12, 2011 at 1:35 AM, Jessy Kate Schingler <
>> jessy at jessykate.com> wrote:
>>
>>> hi john and all!
>>>
>>> (for those i don't know: my name is jessy schingler. you might have seen
>>> me around the lists. i'm starting to work on designing challenges for the
>>> school of webcraft. woo hoo!)
>>>
>>> this is a long email.
>>>
>>> first i mention a few design principles that i've been thinking about,
>>> and then i list a whole bunch of starting-point ideas for intermediate
>>> webcraft challenges. these are totally preliminary, so feel free to rip them
>>> apart, riff off of them, or take them in very different directions. mostly i
>>> want to get a sense which (if any) of these sound interesting, and if you
>>> think i'm headed in the right direction. so, feedback please! (and specific
>>> requests at the bottom).
>>>
>>> *Challenge Design*
>>> * a specific design thought is that challenges should focus on a
>>> measurable outcome, product or activity, but that where possible, the
>>> content should be left up to the user, so that they can customize the
>>> challenge to their own interests, or so that it can be customized to the
>>> content of a specific course/study group/etc.[0]
>>>
>>> * another is to be cognizant to creating some intermediary-level
>>> challenges, challenges that go beyond intro-level stuff. IMHO, part of this
>>> is in using real-world data sets, and asking for questions or products that
>>> don't have clear yes/no or right/wrong answers.
>>>
>>> * incorporate challenges that "reward hard work, not the right
>>> answers."[1] this doesn't mean to reward time spent over output-- it means
>>> to reward peoples' thinking process, and their willingness to struggle with
>>> something unfamiliar and to make learning mistakes. i can see this
>>> manifesting in challenges similar to the above-- by having problems which do
>>> not necessarily have a "right" answer, or possibly haven't been done
>>> before-- eg. working with a new data set, refining or improving existing
>>> work, etc.
>>>
>>> *Challenges Ideas*
>>> (note: these are targeted at *intermediate* web developers)
>>>
>>> * writing scrapers and parsers for large/messy unstructured data. for
>>> example, taking the plain text transcripts from a senate hearing and parsing
>>> it into a structured form that identifies and associated speakers with their
>>> spoken text, and possibly brings in other data about each speaker from a
>>> secondary source.
>>>
>>> * examining an existing site/module/library, and identifying
>>> architectural, design, or deployment choices that are likely to result in a
>>> bottleneck/crash during scaling or high load. what component of the site in
>>> question would be the limiting factor? why? for example, would it be
>>> bandwidth? number of connections? database speed? a really inefficient loop?
>>> how could these expected bottlenecks/load issues be addressed?
>>>
>>> * design an API from scratch (either design-only or design and
>>> implement): for example, pick a site you think is cool, that has an API (but
>>> one that you are not familiar with). without looking at what they have done,
>>> write out a design for what you think the API should look like - what
>>> function calls and features would it support? what should the API calls look
>>> like? what format would the returned data be in? after you're done, compare
>>> with what the existing site has, and compare/contrast.
>>>
>>> * identify 10 things that cannot be done on the web today. what are they,
>>> why are they not possible, what could be done to make them possible.
>>>
>>> * an import/export tool-- for example, write an import tool that grabs
>>> all your tweets and imports them as wordpress posts. (this gets at the idea
>>> but would prefer to make it more useful). the idea would be to get at
>>> working with larger data, working with data you can't control, and having to
>>> work with/convert between interfaces that others have designed.
>>>
>>> * write code/pseudocode for bluetooth pairing using the android API
>>>
>>> * pick your favourite website. what browser standards is it compatible
>>> with? which ones is it NOT compatible with? are there simple changes you
>>> could make, to make it compliant?
>>>
>>> * pick a site you like that does not have a mobile version. grab a
>>> snapshot of their page and any necessary css and js files being used. then
>>> modify the design locally to produce a proper mobile version of the site.
>>>
>>>
>>> *Help* (aka, where i could use your feedback!):
>>>
>>> * do these challenges seem interesting? fun? too much work? imagining
>>> they were fleshed out in a more detail, do they seem
>>> self-contained/manageable enough? too big?
>>>
>>> * are they at the right level for an intermediate challenge?
>>>
>>> * should we explicitly design challenges to be composed (using the output
>>> from one as the input to another)?
>>>
>>> * do you have suggestions for incorporating game mechanics and incentives
>>> as we flesh these out?
>>>
>>> * who evaluates challenge content once submitted?
>>>
>>> * anything else that comes to mind!
>>>
>>>
>>> thanks,
>>> jessy
>>>
>>>
>>> [0] this comes out of some of the questions/concerns i expressed on a
>>> blog post the other day, and some great discussion in the comments:
>>> http://blog.jessykate.com/blog/2011/10/07/heterogeneous-learning/
>>>
>>> [1] see this article philipp sent around to the community list if you
>>> didn't already:
>>>
>>> http://www.wired.com/wiredscience/2011/10/why-do-some-people-learn-faster-2/#
>>>
>>> --
>>> Jessy
>>> http://jessykate.com
>>>
>>>
>>> _______________________________________________
>>> p2pu-webcraft mailing list
>>> p2pu-webcraft at lists.p2pu.org
>>> http://lists.p2pu.org/mailman/listinfo/p2pu-webcraft
>>>
>>>
>>
>> _______________________________________________
>> p2pu-webcraft mailing list
>> p2pu-webcraft at lists.p2pu.org
>> http://lists.p2pu.org/mailman/listinfo/p2pu-webcraft
>>
>>
>
>
> --
> Jessy
> http://jessykate.com
>
>
> _______________________________________________
> p2pu-webcraft mailing list
> p2pu-webcraft at lists.p2pu.org
> http://lists.p2pu.org/mailman/listinfo/p2pu-webcraft
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p2pu.org/pipermail/p2pu-webcraft/attachments/20111018/0f17d092/attachment-0001.html>