minor edits

Anudipa Maiti
2 parents c9307b5e 61fa30d3
Showing 5 changed files with 43 additions and 67 deletions
figures/tables/tableALL.tex
introduction.tex
metric.tex
results.tex
usage.tex
@@ -142,7 +142,7 @@
 \caption{\small \textbf{Evaluating Components of a Value Measure.}
 \PhoneLab{} data is used to weight overall app energy usage in a variety of
-different ways. Ommitted results are caused by Android reporting energy
+different ways. Omitted results are caused by Android reporting energy
 consumption for non-apps such as the Android System.}
 \label{table-results}
@@ -64,13 +64,12 @@ smartphones~\cite{jdpowerbatterylife-url}, we believe this effort is
 worthwhile.
 In this paper we motivate the idea of a value measure and describe an early
-failure at developing one based on measuring content delivery. We begin in
-Section~\ref{sec-usage} by describing how useful such a measure would be and
-the results of being able to answer questions like those posed above, as well
-as formulating design requirements for the value measure itself.
-Section~\ref{sec-measure} presents an overview of possible inputs into such a
-measure and discussion of how each could be measured and how useful it might
-be. In Section~\ref{sec-results} we present at formulating a value measure
-based on content delivered through the video display and audio output---an
-attempt that we consider a failure based on the result of a user survey, but
-one that we hope sheds light on how difficult this challenge may be.
+failure at developing one. We begin in Section~\ref{sec-usage} by describing
+how useful such a measure would be while also formulating design requirements
+for the value measure itself. Section~\ref{sec-measure} presents an overview
+of possible inputs into such a measure and discussion of how each could be
+measured and how useful it might be. In Section~\ref{sec-results} we present
+at formulating a value measure based on content delivered through the video
+display and audio output---an attempt that we consider a failure based on the
+result of a user survey, but a failure that we hope sheds some light on this
+difficult challenge.
@@ -26,7 +26,7 @@ foreground information---such as a pedometer app.
 Patterns of interaction may also be useful to observe, and inputs such as
 keystrokes and touchscreen events are simple to track. However, there is more
-obvious differentation between app interaction patterns between
+obvious differentiation between app interaction patterns between
 categories---users deliver far more keystrokes to a chat client than to a
 video player---so it is clear that interaction statistics will have to be
 used in conjunction with complementary value measure components that offset
@@ -112,7 +112,7 @@ redraws.
 \centering
 \includegraphics[width=\textwidth]{./figures/survey.pdf}
-\caption{\textbf{Participant responses to energy inefficient app sugestions.} The height of each bar
+\caption{\textbf{Participant responses to energy inefficient app suggestions.} The height of each bar
 demonstrates how many of the suggested apps the user is willing to remove for better battery life. }
 \label{fig-survey}
@@ -122,7 +122,7 @@ redraws.
 To continue the evaluation of our simple content-based value measure, we
 prepared a survey for the 107~\PhoneLab{} participants who contributed data
 to our experiment. Our goal was to determine if users would be more willing
-to remove inefficienct apps, as defined using our content-based measure. As a
+to remove inefficient apps, as defined using our content-based measure. As a
 baseline, we also asked users about the apps that consumed the most energy.
 We used each participants data to generate a custom survey containing
 questions about 9 apps: the 3 least efficient apps as computed by our
@@ -2,33 +2,17 @@
 \label{sec-usage}
 To motivate the need for a value measure, we return to the questions posed in
-the introduction. We explore each in more depth, providing a more detailed
-description of how a value measure could be used. These use cases also help
-us develop requirements for our metric, which are summarized at the end of
-this section. We begin by exploring the basic question at the heart of the
-problem: what is the value delivered by an app?
+the introduction and explore each in more depth. These use cases also help us
+develop requirements for our measure, which are summarized at the end of this
+section. We begin by exploring the basic question at the heart of the
+problem: what is the value of an app?
-\subsection{What is Value?}
-
-\begin{comment}
-
-\begin{quote}
-I shall not today attempt further to define the kinds of material I
-understand to be embraced within that shorthand description; and perhaps I
-could never succeed in intelligibly doing so. But I know it when I see it,
-and the motion picture involved in this case is not that.\\
----Justice Potter Stewart~\cite{jacobellisvohio}.
-\end{quote}
-
-\end{comment}
+\subsection{What is App Value?}
 All smartphone users intuitively realize that smartphone apps differ in
 value---an email client, for example, is probably more valuable than a app
-that makes farting sounds, and a chat client is probably more valuable than a
-chat client that only sends the message ``yo''. In Supreme Court Justice
-Potter Steward's famous formulation, they know value when they see it. But is
-it possible to quantify these subjective distinctions and produce a value
-measure?
+that makes farting sounds. But is it possible to quantify these subjective
+distinctions and produce a value measure?
 To argue that this is possible we present two experiments that elucidate
 smartphone app value in the form of both ordinal and cardinal utilities,
@@ -36,12 +20,12 @@ respectively:
 %
 \begin{enumerate}
-\item An advisory will require you to remove some number of apps from your
+\item An adversary will require you to remove some number of apps from your
 smartphone. Order the apps you are currently using from least important to
 most important. The N least important apps will be removed.
 \item Your smartphone will require you to create an energy budget for the
-apps you use. During any discharging cycle, once an app runs out of energy quota
+apps you use. During any discharging cycle, once an app runs out of energy
 you will not be able to use it until you plug in your smartphone. Allocate
 battery percentages to each app you use.
@@ -49,19 +33,15 @@ battery percentages to each app you use.
 %
 We plan to engage smartphone users in studies to explore in more detail which
 of these approaches is more effective, comparing them by comparing users'
-levels of satisfaction under each scenario. As an alternate formulation of
-the second experiment to make it more similar to the first, the adversary
-could remove the apps consuming the least energy up to a given target.
-
-For our value measure we are hopeful that users will prove capable of
-assigning cardinal utilities to apps---as in the second experiment---since
-this matches most directly with our proposed value measure and could provide
-ground truth for a value measure computed automatically. The second
-experiment also engages users directly in the task of allocating energy,
-which is one way that a value measure could be used. However, if ordinal
-utilities prove more intuitive we can still compare the ordering generated by
-our value metric with the ordering generated by users, although the specific
-values of the measure will still require justification.
+levels of satisfaction under each scenario. For our value measure we are
+hopeful that users will prove capable of assigning cardinal utilities to
+apps---as in the second experiment---since this matches most directly with
+our proposed value measure and could provide ground truth for a value measure
+computed automatically. The second experiment also engages users directly in
+the task of allocating energy, which is one way that a value measure could be
+used. However, if ordinal utilities prove more intuitive we can still compare
+the ordering generated by our measure with the ordering generated by users,
+although the values of the measure will still require justification.
 In either case, we believe that these experiments do suggest the existence of
 quantifiable value for smartphone apps. We are not claiming, however, that
@@ -85,20 +65,19 @@ The most powerful use of a value measure would be to compare apps by
 comparing their energy efficiency, therefore overcoming the most critical
 flaw in current attempts to compare or categorize apps by their energy
 consumption alone~\cite{carat-sensys13}. Consider attempting to compare a
-chat client and video-conferencing app by only measuring their energy
+chat client and videoconferencing app by only measuring their energy
 consumption. Unless it is terribly written, the chat client will consume less
 energy. But this does not mean that it is efficient, or that the
-video-conferencing app is not. Ultimately, all the energy consumption
+videoconferencing app is not. Ultimately, all the energy consumption
 comparison truly reveals is that the two apps do different things---which we
-knew.
+already knew.
 Using energy consumption alone even makes apples-to-apples comparison of the same app
 difficult. Given an app that consumes twice as much energy on Alice's
 smartphone than on Bob's, the question of why is left unanswered by pure
 energy measures. Even if usage time can be used to normalize the comparison
 to the power consumed, power consumption alone cannot incorporate differences
-due to the different app features used by Alice and Bob or the different ways
-that they have configured the app.
+due to the different app features or configurations used by Alice and Bob.
 By computing value and, thus, energy efficiency, we can overcome these
 weaknesses. A value measure should allow us to compare the efficiency of two
@@ -108,10 +87,10 @@ video players. Comparisons within the same app category should allow users to
 select the most efficient email client or web browser. Aggregating results
 over all users, differences in app energy efficiency should reflect how well
 the app is written and how well it predicts and adapts to users, not just
-differences in the core features it provides. And when comparing two users
-using the same app, differences in energy efficiency should reflect different
+differences in the core features it provides. When comparing two users using
+the same app, differences in efficiency should reflect different
 configurations or differences in how efficiently the app provides certain
-features, not just that one user is using one feature and another is not.
+features.
 \subsection{Evaluating App Changes}
@@ -132,7 +111,7 @@ defer work on everything else.
 A measure of app value makes it possible to produce a rigorous definition of
 the term \textit{energy virus}: an app that produces little to no value per
 joule. The choice of threshold will require some study, as it is unlikely
-impossible to produce a single efficiency cut-off that cleanly separates
+impossible to produce a single efficiency cutoff that cleanly separates
 malicious apps from ones that are merely poorly-written. Note also that this
 definition of energy virus can be made on a per-user basis. This is important
 since a non-malicious but poorly-written app that continues to consume energy
@@ -150,9 +129,9 @@ allocates a rate to each app and enforces that rate by slowing or stopping
 the app when it exceeds its
 allocation~\cite{odyssey-osr99,cinder-eurosys11,Zeng:2003,pixie-sensys08}.
 However, all of these previous efforts have ignored the critical question of
-\textbf{how rates should be set}. No matter how effective the enforcement
-mechanisms are, systems that rely on rates will fail if they provide the same
-rate to Skype and Snapchat, or to a very efficient app and an energy virus.
+how rates should be set. No matter how effective the enforcement mechanisms
+are, systems that rely on rates will fail if they provide the same rate to
+Skype and Snapchat, or to a very efficient app and an energy virus.
 A measure of value can be used alone or in conjunction with energy consumption
 to help prioritize limited energy resources. The simplest approach is to
@@ -186,10 +165,8 @@ inputs, requiring that it be calculable given data from a single user.
 app generate value and what parts do not.
 \item It should be able to be efficiently computed to not overly consume the
-very resource that it is designed to help manage.
+resources that it is designed to help manage.
 \item It should be derived with little to no input from the user.
 \end{itemize}
-%
-We continue by discussing possible inputs to such a metric.