Use Case: Search Bar
1) Search for tags (typed search)
2) Select tags from available options (drop-down menu)
USER ----
3) Create a tag
4) Remove a tag from the search queue
Requirements:
1. As soon as a syllable is entered into the search bar, the system pulls the drop-down menu, which contain
words (tags) who’s first syllables match the one entered, with the options being updated as each new syllable
is typed out.
2.
Once the tags that exactly match the entered syllable happen to run out, the system can begin to show
relational tags as options. (See 8tracks for a demo)
3. If the user happens to like an option presented in the search bar, he can select it. Once selected, this tag will
be added to the search query queue, and will be an additive to the tags already present there.
4. The search queue can contain a maximum of 10 tags at a time.
5. If a user wishes to type out a tag, and doesn’t see an option being offered in drop-down, he can create that
tag. However, at this moment, the ‘unknown’ tag will not be recorded in the database.
6. To expand, only the tags registered during ‘creation of wanted or for-sale posts’ will be added to the database.
Any unique tag created during search will not be adopted as a database tag.
7. In order to ensure that no duplication occurs, and that a unique tag records all the posts that are relevant to it,
a typed out tag entered into a search query should be recognized as a pre-existing tag, even if the user
doesn’t select the one offered in the drop-down menu. This means that two tags called ‘shoes’ cannot exist, if
the user types out shoes, his tag should be recognized as the existing ‘shoes’ tag, assuming that it has been
created before, through a want/for-sale listing.
8. Each time a new tag is entered into the search query, the feed will aggregate itself to a combination of the
tags present in the query. Posts will be sequenced based on the ones that contain the entire combination, all
the way to ones that simply have one.
9. The above will happen each time a new tag is entered/selected; therefore there will be no need to press the
actual search button.
10. Lastly, each time a new tag is entered/selected, the tags present in the ‘NavBox’ will aggregate too. This is
explained further.
Use Case – NavBox and StarTags
A NavBox, placed below the search bar, contains a collection of tags that are aggregated subsets and relational
subsets of the last searched for tag in the search queue. At the bottom of the NavBox, a user can find 4 StarTags,
which are important constants, namely: Price, Location, Brand and Size, differentiated using different colors. The
functional nature of these tags will be dynamic, being that if a StarTag is selected, it will appear as a blank tag, which
can be filled in according to the user’s wish, within the search query. Similar to normal tags, these tags will also have
a drop-down menu which will only contain previously made StarTag fields, also no duplication should occur.
USER ----
1) Select a tag
2) Select a StarTag  Type into a StarTag
Requirements:
1. As mentioned above, the tags contained in the NavBox will be aggregated to the subsets and relational
subsets of the last tag entered into the search queue.
2. Any tag selected from the NavBox will be added to the search queue the same way as if a tag was selected
from the drop-down menu. A similar aggregation of the feed according to the new combination will follow.
3. As for StarTags, based on the description above, the system needs to record them as separate tables
containing their respective, unique tag types. When a startag will be selected from the NavBox, it will show as
a blank tag in the search bar, which can be typed in. The same drop-down box applies, where a user can
select an existing StarTag.
4. For example, when the StarTag for price, denoted by a ‘green colored tag, is selected, then a blank, green
colored tag will appear in the search box, with the cursor placed at it’s beginning. As soon as a user starts to
type inside it, the search-drop down box opens to suggest existing price points for users.
5.
A large majority of StarTags, such as size, price, location, will be pre-defined in the database. Again, if a new
StarTag is created in the search query, it will be not automatically be added to the database. The database
will only record the addition of a new tag when it transcends into become a ‘Demo Want Post’, which will be
explained in the next use case.
Use Case – MiniWant Post
A MiniWant Post, as it’s name suggests, is a compressed version of the ‘create a want post’ page, that resides in the
right panel next to the NavBox. The purpose of a MiniWant Post is to clone the existing tags in the search query, so as
to allow a speedier process of creating a want. The MiniWant post consists of an image, the cloned MiniTags, an
information icon and a publish button.
The MiniWant Post moves along with the user as he scrolls down the feed, in the right margin of the page. At a certain
fixed point in the feed, knowing that the user has been on it long enough, and that he approves of the tags that he is
subjected to that are contained in the search query, the MiniWant will create a ‘text bubble’ nudging the user to
publish the MiniWant Post of the tags he has selected, so as to receive more real-time offerings. Additionally, as the
user scrolls down, the NavBox disappears, and attaches itself as a mini-version, right on the bottom edge of the
MiniWantPost.
USER ----
1) Click existing image (or default icon) to open gallery  Select another other image
2) Upload an image from drive
3) Add/Subtract MiniTags through MiniNavBox
4) Publish MiniWant
5) Hide MiniNavBox
Requirements:
1. As mentioned above, the MiniWant Post is going to contain an image, and this image will be based on the first
three tags (maximum) present in the search query, and similarly, in the cloned MiniTags.
2. Each time a new tag is entered (up to three) the image will be sourced, in a similar mechanism is aggregating
the feed, or aggregating the options present in the main NavBox.
3. The system needs to use a Google Images API that sources these images, as soon as a tag is selected.
Once more than three tags exist in the search query and cloned MiniTags, the image stays the same based
on what the first three tags are.
4. If at any time, the user wishes to change this image, he can simply click on the image, which will bring up a
gallery. This gallery will be a collection of the results that the API fetches when it sources the first one, two or
three tags. (see www.worldcraze.com for an example). Selecting an image in the gallery will replace the
image present in the MiniWant Post.
5. The user also has a choice of uploading his own image from his personal drive, by clicking on the upload
image icon present in the MiniWant Post.
6. As described above, the NavBox will shrink in size and attach itself to MiniWantPost as the user scrolls down
the feed. If an tag is selected in the MiniNavBox while scrolling, it will follow the same mechanism of being
added to both the search query (which will remain at the top of the page) and the cloned MiniTags present in
the MiniWant Post.
7. As described above, the user will receive a text bubble encouraging him to click on the publish button when
he is significantly midway through the feed. However, this publish button will always be present in the
MiniWant Post, and the user has the option to click on it at anytime.
8. If a user does click on the publish button for the MiniWant Post, the post gets recorded as an official want
post, appearing on the wanted feed immediately. If any unique/new tags were entered in the MiniWant Post,
they will now be registered into the database and regarded as pre-existing tags so forth.
Use Case – Offering Popup
Zotago’s feeds can take three forms, ‘wanted’, ‘for-sale’, and ‘all’, which is a combination of both wanted and
for-sale. Offering popup’s only exist for the ‘wanted items’, which is the default feed the user will be exposed
to when he lands on Zotago. Offerings, as the name suggests, contain ‘for-sale’ items offered to the ‘wanter’,
in the form of another user’s pre-owned items, or links to external items being sold by third party retailers.
‘For-sale’ items will be classified as ‘internal links’, as they are links to product pages of user’s ‘for-sale/preowned’ items, which are a part of Zotago’s own database. For selling ‘for-sale’ items, two instances can occur
when the user is scrolling through the want feed and realizes that he has the item that want post is asking for;
1) the item the user has is already stored in his ‘virtual closet’, 2) the item is not in the virtual closet, therefore
the user would have to create a new listing on-spot in order to create the offering in question.
Ultimately, the offering popup provides the user with three choices when creating an offering; 1. Link the
wanted post to a product page of a third-party retailer by copy-pasting an ‘external URL’.
2. Link the wanted post to a product page of your (user’s) own pre-owned item’s product page, considering
that the item has already been added to the virtual closet.
3. Create a new product for-sale, which will result in an automatically generated unique product URL. This
new product created in the offering popup will be similarly registered in the database as a new ‘for-sale’
product, as would be the case if it were uploaded from the actual ‘create a new post’ section.
It is important to note that all offerings, whether 1), 2), 3) will follow different input format, but the same output
format, i.e. a user can only tell the format of an offering after it has been clicked upon.
USER ----
1) Input ‘external URL’  redirected through Viglink  land on retailer’s product page
2) Upload from Virtual Closet (existing for-sale item)  select an item to sell
3) Create a new item for-sale (treated as an additive to the Virtual Closet)
4) Up-vote another user’s offering
5) Comment on another user’s offerings
6) Tag another user’s handle on your comment to an offering
Requirements:
1. Input external URL into text field
This external URL is the link to an external retailer's item page. Here is where affiliate marketing comes in through
Viglink and Skimlink. We have chosen these two networks as they have the ability to convert plain URL's into
monetised affiliate links, in real time. In other words, any normal link that is put onto the platform, will be transformed
into an affiliate link, that contains a tracker, which will further be used to track CPC, CPA and CPA. For example, if a
user puts in a link for adidas sneakers, and if adidas exists in Viglink's database, then that link will go through Viglink's
redirect loop, that should inform the database that the user was sent to Adidas's site through us. If a purchase is made
through this redirect (CPA), the database needs to record this too. Viglink provides a platform with analytics that we
could use for tracking. The implementation of Viglink and Skimlink into our database is pretty straightforward and
explained on their site.
(Scoring Strategy - continuation of input of external link)
As and when our (or Viglink's) system tracks a new sale or lead, the system needs to award the user who made the
offering that lead to the purchase, a certain number of points. Please refer to the scoring strategy to see how the
breakdown of the 'scores' is going to occur.
2. Upload from virtual closet (if the item already exists)
In this case; the left side of the popup will transition to show a mini-version of the 'for-sale section' of the virtual closet
page. The user will simply be shown images of what exists this closet, where he/she simply needs to click on one to
select. It should be known that each item uploaded for sale is attached to a unique URL. Once the image to be sold is
selected, the database should fetch that unique URL and automatically input it into the URL field that lies below the
Upload from Virtual Closet button.
3. Create an item to sell (if the item doesn't already exist)
If this option is selected, then the left side of the popup will transition to show the mini-version of the 'create a for-sale
post' section of the create a post page, where the user will be required to follow the same procedure as he would
while creating a new for-sale post, details also outlined on the used case. This new item should obviously be recorded
as a for-sale post in the database, and should also show in the 'for-sale feed'
4. Up-vote a user’s offering
System records the up-vote, displays it in the comment section
5. Comment on an offering
A user can comment on an offering, which will be a subsided list, and only appear when the comments are clicked on.
6. Tag another user in a comment
All user profile will be assigned a unique user name, same mechanism as Instagram.
All the above actions will lead to subsequent notifications, details of which will be outlined in future used cases.