Showing posts with label xAppIdeas. Show all posts
Showing posts with label xAppIdeas. Show all posts

Monday, November 23, 2020

Collaborative 'summary of useful points' for Reddit/Hacker News kinds of posts

Sites like Reddit and Hacker news are made up of posts, and each post is about some topic and contains a discussion thread about that topic.

The idea I want to talk about would probably be most suited to certain types of posts, not all posts. It'd be suited to posts like those about news stories, where the discussion threads usually contain a lot of interesting information that fleshes out the picture of the story.

That interesting information tends to be lost amongst a lot of "noise". It'd be quite useful to have a condensed summary of all the useful information dispersed throughout the thread. I could imagine the post having two tabs. A 'thread' tab (shown by default) and a 'summary of useful points' tab.

Is there a way we can incentivise the collaborative work of constructing this "summary of useful points"? And have a sufficiently simple design?


The following are two ideas for how it could be done. These may not be suitable, but they're at least starting points for thinking about the problem.

The first idea is to allow users to add bullet points, where each one contains a 'useful point' summary, and for these to be voted on, where their number of votes controls whether they're shown as part of the summary of useful points.

Notes

  • limit on the size of the bullet points. Perhaps 280 characters, like tweets.
  • if a bullet point has had more than, say, 20 votes, and is in the negative, then it will be hidden (though there's a link to view the hidden items).
  • let the users link a bullet point to the bits of text in the discussion thread that originally made the point. The UI details of this are beyond the scope of this post.


The other idea is that the summary of useful points is updated via a 30 minute cycle that involves a number of phases:

  1. 10 minute phase where anyone can suggest changes to the current summary. Each is limited to 280 characters. People can vote on these suggestions.
  2. 10 minute phase where anyone can write a new summary. They can use the pool of suggestions to help them decide what changes they want to make to the current summary.
  3. 10 minute phase where the new summaries are anonymously shown for voting. When viewing a new summary, users can see a diff of it compared to the current summary.
  4. The top voted summary (if it passes a critical threshold of votes) becomes the new summary, and the cycle repeats.

Notes

  • users can have the thread highlight new comments added since last time the summary was updated. There could be buttons to navigate to next/prev new comment. 
  • users can view history of changes to the summary.
  • the summary tab would show a representation of the update cycle and indicate where it currently is in the cycle. 


Could there be other possibilities? Could there be something that doesn't involve any threaded discussion at all?

Perhaps you could have a system that cycles between two phases. One is where there's a discussion thread. The next is where that content is condensed into a summary. Then this is summary is a seed for further discussion, and then the current summary plus the new discussion is condensed to form the new summary, and so on. At the end of each cycle only the summary is kept (the comments are effectively discarded -- though perhaps a read-only view of them can be accessed).

.

Related

  • I believe Stack Overflow originally wanted to have a feature a bit like this, but that doesn't seem to have panned out. Would be worth investigating.
  • Are there any other systems or designs doing something similar to these ideas?
  • Back in 2005 I wrote Slashdot Article Summaries?, which was a more basic take on the ideas outlined in the present post.

Sunday, July 17, 2011

iPhone app idea: "flow forms"

Some iPhone app ideas. Feel free to make use of them. If you do, an acknowledgement is all I'd ask. I'd play around with some of these ideas myself, but my PhD is what I need to focus on at the moment.

"Flow forms"

This idea is for a novel (at least as far as I know) type of UI for tasks like adding new expenses in an expenses app, where each time you do it you choose from the same set of options and you frequently perform the task.

The point of it is to make doing the task as fast and fluid as possible.

It aims at doing this by removing two sources of friction that you find in the existing form-like UIs normally used to perform these sorts of tasks.

How the normal UIs work. There's a screen for the form, showing the different fields. You tap a field to be taken to a screen for the various options for that field. After you've chosen a value for the field, you're returned back to the main screen for the form.

Friction 1: you have to complete a task before you can see the screen for the next task. A task is either tapping a field to select it, or tapping a value for the field. So you have to tap a field's name before you can see the screen for choosing the value for that field. So when you go to perform that next task you have to take a little bit of time to survey the layout of the screen and find the item you want. Even if you're familiar with the screen's layout and roughly where the item you want is located on it, it still takes a little bit of time to find that item.

Fiction 2: a lot of finger movement. You have to move your finger around a bit - to tap a field here, to tap a field-value there, and so on. This doesn't sound like adding friction, but I think it is something that can be reduced.

These might not sound like much, but if you're frequently using the same form these things start to feel tedious.


The basic idea of the proposed technique.

The form would be just one long page, which would continuously scroll up the screen. Below each field name would be one or more horizontal bands, each divided into equal-sized cells. Each of those cells would represent a different value for the field. To fill out the form the user just needs to slide their finger to the left or right as the form scrolled by.

Essentially the user only needs to move their finger along one dimension, thus simplifying the task. And all they need to do is select field values. They don't have to tap to go to the next field. And the hope is that if the next field is visible on the screen while they're entering the current one, they will have some sense of where the items of a field are located before they come to select them.


Here's some more specific details of one way it could work:


  • the line for selecting a field's value would be divided into N equally-sized segments, where N is the number of different options. (if there were too many options I'd be split up over multiple lines).

  • probably have these lines fairly thick - like 2.5 cm, so that the user has a fair bit of time to select the item as it scrolls past.

  • each segment would contain an icon (or short-description, if there is one) representing the particular value.

  • when the user has their finger on a segment, it would show a label describing the value.

  • the user could swipe their finger across a line to see the descriptions of all the items.

  • if the user made a mistake or missed entering a value for a field, they could scroll the screen back down just like they do in other applications.

  • perhaps they could also be a way to pause the scrolling.

  • perhaps the user could flick their finger up (just like they do in documents on the iPhone to scroll down) to quickly move down to the next field, once they've selected a value in the current field.

  • the user may not want to enter the values for all of the fields. if they've only entered a couple of fields and want to save the record, they could click a save button (or perhaps a two-finger sideways swipe).



Questions

  • how to handle the input of numbers? Would it just scroll a keypad into view and then pause the scrolling while you enter in the value? Or could number-entry also be handled in a similar fashion to the rest of the form entry?

    • it could show eleven choices across two rows: one for each of the ten digits and one for the decimal point.

    • if after you selected on of those you moved your finger over to a 'gutter' area on the side of the screen it would assume you'd finished entering in the numeric value.

    • but if you instead kept your finger within those gutters it would add another two rows for selecting another digit or decimal place.

    • the above process would continue on until you'd finished entering the number in.


    of course the question is whether this, or some alternative, would be convenient and fast enough.

  • similarly, how to handle the input of textual values (such as for a 'note' field for an expense item)? Would it just scroll up a keypad and a text area and pause the scrolling while you enter in the value? Or might there be useful way of entering it in a 'flowing' fashion, like I described concerning entering in numbers?



Notes

  • ideally it would show the fields in an order such that the most commonly used fields come first. I typically just enter two field values, and if these were the first two that came up I could just save the record after I'd selected values for them.

  • since the user is likely to buy the same item a number of times (e.g. I buy the same coffee everyday, or I might get a packet of chips every day) their muscle memory may be able to learn the path their finger traces out to enter the expense for that item.

  • to make entry even faster, you have an option to control the speed it scrolls at. As you got more familiar with it you could increase the speed. Perhaps there could be a speed-control slider that sat at the top of the screen next to the save button. It could even have a setting to automatically -- but gradually -- increase the speed over time. For example, it could get gradually faster every month.



Another question I have is: are there any other sorts of tasks or apps that this kind of UI technique might be useful for?

And finally, obviously it'd require a lot of experimentation to figure out how best to have the UI work. There's lots of different ways the basic idea could be done. Hopefully there would be one that is workable and which would make the task quicker and easier to perform.

iPhone app idea: "battlechat"

Some iPhone app ideas. Feel free to make use of them. If you do, an acknowledgement is all I'd ask. I'd play around with some of these ideas myself, but my PhD is what I need to focus on at the moment.

"battlechat"

An app for a kind of verbal battle amongst friends.

I'm thinking of like the verbal battles rappers do. I'm also drawing on my own experience when I used to be bored at work I used to have a lot of email conversations with a friend that basically came down to creative ways of insulting each other.

So this'd be an app that was like a mix between real-time (textual) chat between a bunch of friends, but with some competitive elements thrown in, to make it a bit game-like.

There'd be lots of different ways you could do this kind of thing, and getting it right would probably involve a lot of experimentation.

Here's one possibility.

The game is played in rounds. Each round lasts a set amount of time (e.g. 15 seconds). Players can type in whatever they want to say. And obviously they can make comments on what the others say.

At the end of the round, the players anonymously vote on who said the 'best' stuff.

The more 'votes' you get, the more "ammunition" you can use and you can choose who to expend it on. Players would start off with some amount of health and when they're 'fired on' they loose health. They get knocked out when their health reaches zero, and have to sit on the sidelines, so to speak.

Last person standing wins.

-

I can imagine the players being represented by their twitter or facebook picture, but with cartoon facial expressions and arms and legs attached to them (the facial expressions wouldn't have to be matched up with the face in the picture, or wouldn't even require a face in the picture, for the effect to work, I suspect... the idea is to do it for comic effect). Then when they're hit with some ammo, the cartoony facial expression shows an expression of pain, falls over, etc.



After thinking of this idea I came across Turntable.fm which while very different also works on the idea of adding game-like elements to more socially-oriented activities. That's a general area that could be explored.

iPhone app idea: 'ground control' side-scrolling car game

Some iPhone app ideas. Feel free to make use of them. If you do, an acknowledgement is all I'd ask. I'd play around with some of these ideas myself, but my PhD is what I need to focus on at the moment.

'ground control' 2D side-scrolling car game

In this game the player doesn't control the car, but the ground level. Sliding their finger up raises the height of the ground at that point, and also increases the slope of the ground leading up to that point. Sliding their finger down lowers the ground level.

The screen is constantly scrolling across with the car always moving forwards. The car might always sit about 1/3 in from the left of the screen.

Steeper uphill makes the car move slower. Steeper downhill makes it go faster. A small uphil can be used as a jump, making the car fly through the air.

These techniques could be used to make the car avoid static and moving obstacles, jump over crevices, etc.

---

update, 02 Aug 2011: I just heard about the game 'Bumpy Road' which works using this kind of mechanic (see the video on the linked page). It seems to use the mechanic in a different way, though. It seems it as effectively like an alternative to having a 'jump' button. I was thinking more of it as a way of changing the landscape ahead of the car, to speed it up or slow it down or to create ramp-like jumps.

update, 10 May 2012: The iOS game Contre Jour involves a mechanic where you raise and lower the ground-level.

Sunday, October 25, 2009

An idea for a multi-touch rhythm game

Here's an idea for a rhythm game for the iPhone that exploits the phone's multi-touch capabilities. 

Most rhythm games involve pressing or tapping on one of a fixed set of positions.  In Guitar Hero those positions are button positions, in Dance-Dance Revolution they're floor tiles, and so on. 

Touch-screens let the taps be anywhere on the screen.  Like in Elite Beat Agents on the DS where circular markers pop up on the screen showing you where to tap.   The sequence of places to tap usually follow a spatial pattern - eg in a line or an arc.  Following these patterns around adds some interest to the game.  It's more dynamic. Rhythm and movement work well together.  

On a multi-touch screen you could have a different style of game.  It could have the user make multiple touches at once, where the had to simultaneously tap points in a particular spatial pattern.  It might get them to simultaneously tap three points arranged in a line, then simultaneously tap four points arranged like the end points of a cross. The focus would be on the progression of spatial configurations.     

And just like how Elite Beat Agents also sometimes made the player slide the stylus along a path, this game could make the use simultaneously slide fingers across multiple paths.  For example, where their fingers start out at like the four corners of a box and have to simultaneously slide towards the box's center. 

I'm imagining something where it's like the players fingers are performing a dance. Something a bit like twister for your fingers, but rhythm elements to it. Maybe you could call it Finger Dance.

(this is the first time I've composed a post on my iPhone - nice use of a bus trip)