net-art-uchicago / cta-file-sharing

a collaborative artware project by Media Art and Design students at the University of Chicago.
GNU General Public License v3.0
2 stars 15 forks source link

The Concept #1

Open nbriz opened 1 year ago

nbriz commented 1 year ago

At present the concept is to produce an app that users can use to share geo-tagged data along the CTA trains. A user of this app will be able to share some sort of data through the app when their riding the CTA, this data will be geo-tagged with the location where they shared the data. Other users will be able to see data shared by others if/when they are also riding the CTA near the location the original data was shared. This concept needs to be fleshed out a bit more before we can start working on it, respond below with answers to the following questions...

What is being shared?

Technically speaking, there's all sorts of stuff users can use our app to share, but we should consider what sort of experience we're trying to create and what sort of stuff makes the most conceptual sense. Here are a few different concepts/examples:

How we choose to answer this question will greatly impact the theme of our artware. think about what sort of experience you want to create with this project.

What is the GPS angle?

After our brainstorming session we definitely identified wanting to introduce geo-specific functionality (like geocaching), where files/data/etc would only be available when the app is used in a specific location... but we never landed on anything too specific. Closest we got was the idea that we limit the activity to the CTA trains, which can definitely be interesting: we could come up with a concept that involves exploring the city through riding the trains, or maybe a concept that has to do with waiting at CTA stops (as mentioned above).

If we use GPS to tag the data users share, then that data will be in that specific spot (pinned to the train-track so to speak), but what if users left digital files on the trains themselves? A few of us expressed interest in working with the city's API, we could use the Train Tracke API to keep the data users shared "on the train" by changing it's locations such that it matches the trains as they move along the tracks.

Or maybe you have a different idea entirely for what our GPS/GEO angle should be? In any case, here too I'd recommend that you think about the "concept" rather than the tech (we'll cross that bridge next week), again what sort of experience are we trying to create? What is this artware going to be about?

What else?

...if there's anything else that came up during our brainstorm yesterday that really resonated with you which I've not mentioned above feel free to bring that back up in the comments below as well.

bermanisaac commented 1 year ago

I think asking users to share photos is a pretty compelling angle, perhaps photos taken on the train. That would ask us to interface with the phone's camera in the application, which hopefully isn't too bad.

In terms of using GPS/the city API, I like the concept of geo-tagging photos and only allowing you to access/contribute to files shared in your direct location. It does look like it will be quite difficult to directly move files' "location" with the trains. I looked a bit more into the API and it seems that they haven't yet released a feature to get real-time location data for the trains, just information like "this train arriving at this station in n minutes".

nbriz commented 1 year ago

It does look like it will be quite difficult to directly move files' "location" with the trains. I looked a bit more into the API and it seems that they haven't yet released a feature to get real-time location data for the trains, just information like "this train arriving at this station in n minutes"

@bermanisaac this is true... but that's only if we needed it to be extremely accurate. but remember, this is "art", we want this to be more poetic than it is practical, so we could always extrapolate from the arrival times where we think the train might be. if moving the files along w/the train was conceptually important to us, an approach like this would be good enough to convey that concept

bermanisaac commented 1 year ago

I could also see a version of this project where files become "unavailable" while traveling on a train, and you can only access files that happen to be waiting for the train with you at the station, making for a much more ephemeral experience.

akhaiat2 commented 1 year ago

I personally believe that using the CTA bus data will solve @bermanisaac's concern of getting real-time location data (in this case buses). I think that uploading .txt files would be compelling: I always wonder what others are thinking of on the bus, especially not just at bus stops but also on the bus. Here's a pdf of the documentation for the bus tracker API if anyone is interested.

Screen Shot 2022-10-29 at 11 57 03 AM

I think my goal for using the CTA was to connect other individuals' artwork with one another, whether that be a small sentence or an entire poem written on the bus. Let me know your thoughts!

bermanisaac commented 1 year ago

Using buses makes a lot of sense then! A lot of the ideas should translate directly then -- tie files that users submit to a certain bus or bus route and present to users the files that are tied to the bus they're currently riding.

Would love to hear others' opinions on images vs txt vs any other ideas, I could honestly go either way.

ajchu28 commented 1 year ago

Something that interests me is the dichotomy of consuming/creating and how that relates to the similarly opposing states of waiting and moving that you do on the cta. Perhaps there could be different states of our project, where when you are waiting for the bus/train (ie at the stop), some set of functionality unlocks which lets you create. Then, when you're riding the transit, the consume functionality becomes available. I said wait -> create and move -> consume because that feels most natural to me in terms of how I feel when I ride the cta, but definitely doesn't have to be that way!

As far as what that functionality looks like, I think I'm more drawn to text because it would give you a glimpse into something other people have created that's a reflection of how they're processing their surroundings, versus an image may be a more universal experience since we're inherently constricted to similar visual experiences when taking public transit.

andrewscottcohen commented 1 year ago

I think the wait -> create and move -> consume idea is intriguing. I also agree that txt will be insightful. Furthermore, I feel overwhelmingly inundated with images due to social media. Even while on the CTA I often go onto instagram/twitter and get bombarded with visuals. I think the txt direction will allow people to properly sit and contemplate in a way that traditional uses of the internet currently do not.

nbriz commented 1 year ago

@ajchu28 i love wait -> create and move -> consume, not only is it conceptually interesting, but the language u've given it can really start to help us imagine/design what the UI/UX can be.

also totally agree with ur rationale + what @andrewscottcohen said behind text vs images.

cal-ledoux commented 1 year ago

When discussing this wait -> create and move -> consume dichotomy, how are we going to decide what one can consume when moving? Can it be any texts originating from the stop a person got on at, or is there another way we decide what media a person can consume?

ashantiowusu-brafi commented 1 year ago

wait -> create feels like a movement of asynchronous data move -> consume feels like a movement of synchronous data

What if there is a threshold of the number of users that cause this change in data movement? (i.e. real-time data affects how created "objects" are stored or shared or posted. You get on the bus and open "wait create" here asynchronous data is generated by the user and stored? posted?, three more people join, and the app begins running a synchronous "move consume".

Maybe the interface of the app has two pages. One is a map of your "current route" (use real-time data of destination, speed, etc). The second page is the "create space" where the user is generating the "art" on the app which is asynchronous data. What happens once the synchronous shift occurs? Would the "create space" change? Would the map be affected?

akhaiat2 commented 1 year ago

Just wanted to share this quick Figma diagram I made of a potential wireframe for the app.