We'll remember your contact info. for this session.

RSS_reader_step1.0

Comments (7)

Martin

Martin replied 1 year ago , re: Michele's Version 3 from 1 year ago

Having looked at all of the RSS designs, here is my review:

I feel like the current design focuses too heavily on the technical manifestation on what RSS feeds are. We should not really expect the primary interface to be entering a URL, nor do I think should RSS be prominent in the application as names of things.

Workflow wise, this is how I see it working: You browse online, you get to a page that has an rss feed, the browser has an added option that maybe looks like an eye or even the rss icon. Clicking on this would subscribe you and move you inside the app. Inside the app we would have a category per feed, named using the title meta-data. Deleting the category would delete the feed.

Michele

Michele replied 1 year ago , re: Michele's Version 3 from 1 year ago

Integration is not the scope of the current mock-up: this mock-up represents the app "as it is", regardless of what kind of communication can be implemented between the browser and the RSS reader.

As regards naming, this is a wireframe, so every text in it is placeholder text, and every reference to RSS can be easily removed.

Integration is a very good thing, but on the other hand i don't feel like removing the URL input box. Think of a scenario where the user picks a non native browser over the native one. It's higly likely that such a browser will lack the RSS integration: why shuold I force the user to copy the URL of the site, open the native browser, paste the URL and then subscribe to the feed?

BTW. the integration you described is already implemented in MeeGo :)

Homero

Homero replied 1 year ago , re: Michele's Version 3 from 1 year ago

Why not insert a search space where user can insert URL, a description, the website name, what else? More, IMO the app have to be pre-loaded categories (such as technology, cars, photos, news, etc) and the user can select feeds inside these categories.

Michele

Michele replied 1 year ago , re: Michele's Version 3 from 1 year ago

What do you mean by search space?

I personally hate preloaded categories, but I see no harm in designing an alternate mockup with categories available :)

Homero

Homero replied 1 year ago , re: Michele's Version 3 from 1 year ago

For "search space" I mean a search box when you can enter the URL, names, descriptions, etc + the preloaded categories. I think preloaded categories are a good way for organizing things and make easier for users to discover new websites writing about topics they like. For example, if you like to read things about cars, is a good option to have a cars section suggesting new feeds.

We can put only a few categories that help users to get content at the beginning, at the first time seeing the app.

Homero

Homero replied 1 year ago , re: Michele's Version 3 from 1 year ago

Michele

Michele replied 1 year ago , re: Michele's Version 3 from 1 year ago

as regards the searchbox, I believe we should rely on the native searchbox which is placed, according to what seems to be the current ubuntu phone UI, at the top of the screen, in the upper left corner.

are there specific guidelines about in-app search?

Add a Comment

Some HTML is allowed. You can also use Mockups text formatting markup.
Ex: *bold* _italic_ &underlined& {color:#FF0000}colored{color} * New lines with asterisks for bulleted lists.

Are you sure you want to delete mockup "XYZ?"

Your mockup's data and history will be deleted forever!

Notify project members