Transcript Contoso Catalog

Design decisions
App type
Explore the key design decisions
for this app.
Language
Development
technologies
Tools
UX
Data storage
TIP
Click
to get more information.
Deployment
Provider-hosted This is a provider-hosted app that
runs as an Azure web site that
provides a product catalog stored in a
Windows Azure SQL Database.
managersand
can JQuery
propose
Visual C#, HTML5,Product
CSS3,
JavaScript,
This
provider-hosted
app is
changes to product prices. A
implemented as a Model-ViewSharePoint workflow manages the
Controller (MVC) website hosted as an
approval process for price changes.
Azure website. Server-side logic and
The app provides a custom view for a
data access
is written
in Visual
C# and
SharePoint 2013 client-side
object
model,
ADO.NET,
SQL
product
manager
to access
the
This
provider-hosted
app
the modern, responsive user interface
workflow and approve
or rejectusing
price
communicates
SharePoint
is implementedwith
in HTML
5, CSS3,
changes.
This type of
architecture
the
.NET client-side
object
model, is
JavaScript,
and JQuery.
perfect for for
the managing
provider-hosted
specifically
SharePoint
model.
and list items used in the
Visual Studio 2013lists
This
app was
developed
using
Visual
approval
workflow.
All other
data,
Studio
such
as2013.
Category and Product details,
are stored in Windows Azure SQL
Database and managed by robust
MVC, HTML5, CSS3,
JQuery
SQL
stored
Therobust
app uses
TheJavaScript,
app
hasprocedures.
aand
modern
and
ADO.NET
to call the
user experience.
Thestored
user interface
procedures
and
display
data whereare
elements and
the
user experience
required.
implemented
MVCand
Views
and
The
app needsusing
to store
maintain
Windows Azure SQL
Database
(Category,
Product),
HTML5, and
make
heavy use of
CSS3,
relational
data
for categories
and
SharePoint List (Proposals)
JavaScript,Windows
and JQuery.
products.
Azure SQL
Database
tables
are ideal for
The
app can
be deployed
to this type
of
data. Approval
in the
SharePoint
online data
or toused
SharePoint
approval
process
is stored in
on-premise
environments.
It can also
App catalog or the
Office
Store
SharePoint
lists,
where
it
is
easily
be published to your organization’s
accessed
by or
thetoincluded
workflow.
app catalog
the Office
Store.
Design decisions
Data
Data
How should data be managed?
Storage type
Database or list?
Relationships
How are relationships
implemented?
Location
Host site or app web?
Creation
User? Declaratively?
In code?
Database
How
Host
User?
are
site
Declaratively?
relationships
or
orapp
list? web?
Inimplemented?
code?
It willProposals
Any
The
data
given
notmodel
be
Category
a list
good
is isrelational.
required
can
userhave
experience
Categories
only
zero,by
one,
to
theforce
or
have
workflow
more
related
theproducts.
user
included
Products,
to create
This
in the
which
theapp,
couldbybethe
one-to-many
and
proposal
implemented
listapp
manually
relationship
itself. Therefore,
withcan
lookup
beitimplemented
should
fields in
beastored
SharePoint
by using
in theprimary
list.
appHowever,
web.
key
givenforeign
and
the fact
key
that
constraints
atomic transaction
in Windows
processing
Azure SQLis Database.
required for
Because
the
list
must
reside
in
the
app
site,
it
can
be
created
inserting, updating and deleting data, this model should
be
declaratively
in
Visual
Studio.
implemented as a Windows Azure SQL Database. Data that is used in
workflows,
however,
is stored
in a stand-alone
SharePoint
list.so that is
The workflow
included
in the app
requires the list
definition,
another reason to create the list declaratively in Visual Studio.
Design decisions
Entity relationship diagram
Entity relationship diagram
Category
Fields
•
•
•
•
CategoryID
Name
Description
ImageURL
1
has
..*
Product
Fields
•
•
•
•
•
•
CategoryID
ProductID
Name
Price
Description
ImageURL
1
has
..*
Proposal
Fields
•
•
•
•
•
•
•
•
•
ID
Title
ProductID
ProductName
Existing Price
ProposedPrice
ProposedBy
ReviewedBy
Status
Design decisions
The PriceChangeApproval workflow
The PriceChangeApproval
workflow
How should the workflow function?
How should
it run?
Manually or
automatically?
What should
it do?
What data does it
interact with?
How does
it appear
to users?
Native SharePoint UI or
custom UI in the app?
Manually
What
Native
data
SharePoint
ordoes
automatically?
it UI
interact
or custom
with? UI in the app?
The SharePoint
workflow runs
should
task-based
when
run aautomatically
new
UI for
item
listsisand
added
to implement
workflows
to the Proposals
isthe
very
business
different
list in
rule
the
that web.
app
from
no
theprice
fluid
It reads
changes
appthe
UI, pertinent
and
can be
is potentially
made
datainfrom
the
confusing
that
database
list, and
such
until
laborious
asa the
director
current
to gives
their approval.
price
directors
of the
who
product,
are
It isfamiliar
not
theoptional,
proposed
with the
and
app
new
sobut
price,
should
perhaps
and
notthe
be
not
person
left
that
to familiar
the
whouser
is to
decide
proposing
with
SharePoint
whether
it. Theor
workflows.
workflow
not to run
then
Therefore,
thebuilds
workflow.
aastreamlined
task
The
to design
include
process
ofa this
friendly
for
app
includes provisioning
representation
interacting
withofworkflow
thatalogged
custom
datadata,
should
list in
and
the
beassigns
app
provided
web
theto
right
task
store
to
in proposed
the
members
app itself,
of
price
the
so
the
Directors’
changes,
directors
group.
sodohaving
not need
the workflow
to performrun
multiple
whenever
operations
a new proposal
in
is
entered from
SharePoint
just
the
toapp
approve
via the
or client-side
reject a proposed
object model
price change.
is the ideal
solution.
Design decisions
Categories
Categories
What features should be
provided in the Category UI?
Category
displays
Browsing
actions
Editing
actions
How should categories
be displayed?
How should category
browsing be
implemented?
Who can edit categories,
and how do they do so?
Who should
How
can editcategories
category
categories,
browsing
beand
displayed?
how
be do
Categories
implemented?
they
doshould
so? be displayed in an engaging, touch-friendly, tile-
based UI. Given that the number of categories relative to the number of
Product
managers
and
product directors
can editshow
categories.
This includes
A
simple
click
onscreen
a “browse”
actionisshould
the
contents
of the
products
is
low,
real
estate
not
too
much
of
a
concern.
updating
names, descriptions,
and image URLs.
selected
to is
the
user.
Browsingcategory
categories
likely
to be performed frequently by a traveling
Product
managers
and product
directors can
also create
and should
delete categories.
sales
team
on mobile,
devices,
so can
this
be an easy
All users,
regardless
oftouch-enabled
their group membership,
browse the
When
a
category
is
deleted,
all
of
the
products
that
it
contains
are
also
deleted.
process.
category data model provides for images to be used
as the
contents The
of categories.
background
for the user
category
tiles.
The security-trimmed
interface
provides actions for adding, editing, and
deleting categories. These actions are not shown to sales folks.
Design decisions
Products
Products
What features should be
provided in the Product UI?
Product
displays
How should products be
displayed?
Browsing
actions
How should viewing
product images be
implemented?
Editing
actions
Who can edit products,
and how do they do so?
Who should
How
can editproducts
viewing
products,
product
beand
displayed?
how
images
do they
be
Given
that the number of products relative to the number of categories is
implemented?
do
so?
potentially high, screen real estate is a concern. Therefore, the products should not
Product
Products
managers
should
beand
displayed
product
indirectors
ashould
list, along
canshown
with
edit various
products.
includes
depending
updating
onthe
be displayed
as tiles,
but
instead
be
in a listactions
toThis
make
best use
of
the
names,
user’s
descriptions,
security group.
and image
Most of
URLs.
the relevant
If, however,
dataa for
price
a product
change proposal
should beisshown
available
screen.
in this list
made,
then
view
rather
but,than
to save
committing
screen real
thatestate,
change
thedirectly
product
toimages
the database,
shouldthe
not be
Actions
for working
with
should
be displayed
alongside
shown directly.
custom
approval
Instead,
workflow
a “view”
isproduct
started.
actiondata
should
be included
to show the
product in
a
client-side
pop-up.
the
products
in the
and directors
should support
gestures.
Product
managers
andlist,
product
can also touch-based
create and delete
products.
However, only product directors should be able to see the workflow actions.
Sales folks should only the see the product details and the image viewer.
Design decisions
Architecture
Architecture
Azure SQL Database hosts the database
WhatWindows
are
the
main components of
and deals with all transactional data operations
the app,
such and
as: where do they run?
•
•
•
•
Retrieving category data.
Adding, updating, and deleting category data.
Retrieving product data.
Adding, updating, and deleting product data.
The provider runs as an Azure web
site. This provides global access to
app for a traveling sales team, and
supports reading and writing to the
Windows Azure SQL Database.
The provider adds data to the
proposals list in the app web when a
price change is proposed. This action
automatically starts the approval
workflow.
The app accesses the list and
workflow in an on-premise SharePoint
2013 environment but could also
work with SharePoint online.
The workflow retrieves data from the
Proposals list, and creates suitable tasks for
Directors to approve or reject price changes.