Założenia funkcjonalne Dietphone, przykładowej aplikacji użytkowej dla Windows Phone 7 « Pabloware + Windows Phone

Pabloware + Windows Phone

Niezależny blog firmy Pabloware o systemie Windows® Phone 7

Założenia funkcjonalne Dietphone, przykładowej aplikacji użytkowej dla Windows Phone 7

Aplikacja ma obliczać mierniki wartości odżywczej takie jak wymienniki węglowodanowe (WW) oraz wymienniki białkowo-tłuszczowe (WBT). Założono, że aplikacja oblicza również wartość energetyczną (kcal), pozwalającą wykorzystać aplikację przez osoby stosujące dietę o ustalonej wartości energetycznej.


Samo w sobie obliczanie wartości odżywczej posiłku nie jest skomplikowane, ale wymaga użycia danych o zawartości poszczególnych składników odżywczych (np. białko, tłuszcz), w produktach wchodzących w skład posiłku. Zwykle w posiłku jest przynajmniej kilka produktów, co wprowadza już pewną komplikację, trzeba bowiem odnaleźć dane każdego produktu. Założono więc, że aplikacja będzie posiadać gotową, możliwie pełną, edytowalną bazę produktów, z zapewnieniem ich szybkiego wyszukiwania tekstowego i przeglądania według kategorii, aby można było z niej sprawnie dodawać produkty do posiłku.

Ponadto przydatne podczas przeglądania produktów może być prezentowanie wizualnego znacznika wartości odżywczej produktu, w porównaniu do innych produktów w swojej kategorii. Pozwoli to użytkownikom odnaleźć alternatywne produkty o bardziej korzystnym rozkładzie wartości odżywczych.

Składniki odżywcze w produktach powinny móc być definiowane w odniesieniu do przynajmniej dwóch jednostek ilości produktu: gramów, jako jednostki podstawowej i drugiej jednostki opcjonalnej. Ponadto jednostki powinny móc być łatwo dodawalne do aplikacji przez programistę lub użytkownika, a domyślnie dostępną dodatkową jednostką powinny być mililitry.

Dla wygody użytkownika zasadne jest zapewnienie możliwości zapisania predefiniowanej porcji konkretnego produktu, takiej jak np. szklanka mleka. Co więcej, kiedy użytkownik zdefiniuje dane produktu w odniesieniu np. do szklanki i poda, że szklanka to np. 200ml, aplikacja powinna umożliwić korzystanie z tych danych dla dowolnej określonej w mililitrach ilości produktu. Natomiast ilość w gramach powinna móc być podawana w odniesieniu do 100g, bo w takim ujęciu informacje te są umieszczane na opakowaniach produktów spożywczych.

Po zakończeniu edycji produktu, jego dane powinny być walidowane pod względem spójności wprowadzonych składników odżywczych (np. w odniesieniu do wartości energetycznej, którą można wyliczyć z pozostałych danych), jak również ich kompletności. Podobnie, na koniec edycji posiłku, powinna nastąpić walidacja. W celu wychwycenia popełnionych przez użytkownika podstawowych błędów, podczas wprowadzania posiłku.

Jak wspomniano wcześniej, dodawanie produktów jako składników posiłków, powinno odbywać się jak najsprawniej. Należy to działanie połączyć z podawaniem ilości produktu oraz uwzględnić przy tym predefiniowane porcje produktu, a domyślną jednostką powinny być gramy. Użytkownik podczas dodawania składników posiłku powinien mieć dostępną informację o bieżącej sumie wartości odżywczych (WW, WBT i kcal) w posiłku, przy czym powinna to być informacja dobrze widoczna. Podczas edycji posiłku użytkownik powinien mieć też możliwość usuwania składników oraz zmiany ich ilości.


Ponadto należy zapewnić możliwość wglądu przynajmniej w sumaryczne informacje o każdym posiłku, a najlepiej w listy wszystkich składników każdego posiłku. Dlatego też założono, że każdy posiłek będzie dodawany do dziennika posiłków, z możliwością jego późniejszej edycji i oczywiście wglądu. W celu szybszego odnajdywania, założono uszeregowanie posiłków według chronologii (wskazana jest funkcja szybkiego przejścia do konkretnej daty) oraz możliwość ich filtrowania według nazwy użytego produktu. Przyjęto, że każdy posiłek będzie mógł mieć przypisaną wybieraną z dostosowywalnej listy, opcjonalną nazwę (np. „śniadanie”, „obiad”, „kolacja”) oraz będzie zapamiętana data i godzina ukończenia dodawania w aplikacji tego posiłku, jak również będzie można dodać do niego notatkę.


Zakłada się, że interfejs użytkownika aplikacji mobilnej powinien zostać zaprojektowany w zgodzie ze standardem aplikacji na system Windows Phone 7, a więc powinien być przeznaczony do użycia „w biegu”, bez konieczności wykonywania niebędących niezbędnymi lub zbyt precyzyjnych czynności oraz być zgodny z wytycznymi projektowymi tego systemu i mieć spójny z nim wygląd. Bardzo ważna jest również szybkość działania aplikacji, ze szczególnym uwzględnieniem szybkości uruchamiania, aby aplikacja ta mogła być uruchamiana wielokrotnie w ciągu dnia i użytkownik mógł ją obsłużyć jak najszybciej.

Autor założył również, że przydatne będzie zapewnienie możliwości dostępu do danych zgromadzonych w aplikacji mobilnej także w aplikacji webowej, która w przyszłości mogłaby również zostać przygotowana. Ma to już na tym etapie pewne znaczenie dla implementacji, w której należy uwzględnić gotowość modelu biznesowego na synchronizację danych z serwerem, przy czym założono, że aplikacja będzie zawsze pracować asynchronicznie na lokalnej kopii danych, oczywiście z powodu szybkości i niezawodności takiego rozwiązania.

No Responses to “Założenia funkcjonalne Dietphone, przykładowej aplikacji użytkowej dla Windows Phone 7”

Kanał RSS z komentarzami do tego wpisu. TrackBack URL

Leave a Response