# Web

## ifc Upload

### Requirements
 - Ist im Web ein genialer hook, um die Leute in die ArchScape-Welt zu ziehen.
 - Der User muss einfach und schnell sein Modell in der Welt sehen.

### Limitations
 - Der Grossteil des aktuellen Codes befasst sich mit der Konfigurierbarkeit von Modellen, welche anschliessend Kunden präsentiert wird. Dieser Code sollte nicht würs Web dupliziert werden müssen. Demnach sollte der User die Konfigurierbarkeit des Modelles im Web nicht vermissen.
 - Tiefergehende Interaktionen mit dem IFC-Modell sollten nicht entwickelt werden, da es dafür bereits bessere Tools gibt. 

### Issues
 - Ist die Konfigurierbarkeit im Web zwingend nötig?
   - Visuell kann man es auslassen und ein statisches Gefühl der Architektur vermitteln (Das visuelle Modell als Träger von Daten, nicht als visualisierung der Daten).
   - Sind verschiedene Varianten für den Kostenrechner nötig?

## Modeler

### Requirements
 - Ist im Web ein genialer hook, um die Leute in die ArchScape-Welt zu ziehen.
 - Sollte sowohl mit, als auch ohne Internet funktionieren (Office 365, Google Docs, etc.).
 - Sollte einfache, ein und ausschaltbare Elemente beinhalten.
 - Die einzelnen Konfigurationen sollten als Snapshot abgespeichert werden (exportierbar)

### Limitations
 - Der Code für die Bearbeitung des Modells sollte wenn möglich nur im Web notwendig sein.
 - Da es sehr wahrscheinlich ist, dass wir später die Modelle in der App ebenfalls darstellen oder sogar bearbeiten wollen, können wir trotzdem keine bestehenden Code-Libraries im Web benutzen.
   - Falls trotzdem Libraries zur Darstellung im Web verwendet werden, müssen die Snapshots als OBJ exportiert werden können.

### Cost
 - Zahlreiche Komponenten müssen mehrfach entwickelt und jeweils aufeinander abgestimmt werden. Einige Beispiele:
   - Navigation im Modell
   - Interaktion mit der 3D-Welt
   - Werkzeuge zum Platzieren und Adjustieren von 3D-Elementen
   - Speichern und laden der 3D-Modelle
   - Einheitliche Benutzeroberfläche
   - Polishing der Web- und Desktop-Applikation
   - etc.
 - Weitere Zerstreuung des Entwickler-Teams statt der Stärkung des aktuellen Teams:
   - Die Entwicklung des Modelers in der App, hätte zu einem weiteren Developer geführt, der den Core versteht. Der [Bus Factor](https://en.wikipedia.org/wiki/Bus_factor) bleibt weiterhin kritisch.
   - Besagter Entwickler kennt zudem die Funktionsweise von Unity und dem RGDK (Raumgleiter DevelopmentKit, unsere Codebase[^1], bzw.) und kann demnach an der App mithelfen, wenn nötig.
   - Die investierte Zeit von SG führt zu keinem längerfristigen Wachstum des App-Teams. 
   - Mit dem aktuellen Trend, kommt die Entwicklung der App zum kompletten Stillstand, da alle Zeit ins Zusammenfügen und ins Betreuen der Module investiert wird.

### Issues
 - Wie können die notwendigen Ressourcen aufgewendet werden?
 - Welche Bereiche sollen (später) in die App übernommen werden können? -> Dürfen Libraries verwendet werden und wozu?

# R&D Team
## Aktuelle Einschätzung 

| Codebase[^1] | Projekt | Grösse | Mitglieder |
| ------------ | ------- | ------ | ----------------- |
| Unity | ArchScape | sehr gross | SG |
| Unity | WebAsset Materials | mittel | **BK**, SG |
| kein Investition | Schindler | gross | **SR**, SG |
| Unreal | FloorPlanner | sehr gross | **FR**, RD,  SG |
| Unreal | RGInteraction / ArchInteraction | wechselnd | RH, GS, SG |
| Unreal | PixelStreaming | gross | RH |
| keine Investition | Projekte | sehr gross | FR, **RD**, SB |
| Web API | dxf, Pano, etc. | wechselnd | **RO** |
| Web API | Kosten-Tool | gross? | ??? |
| Web Database | ArchNet | gross (steigend) | **Binarium**, SG |  
| ??? | Modeler | sehr gross | **GS** |  

#### Caption
 - Grundlage: Schätzung von: SG
 - **bold**: Grossteil der investierten Zeit. Personen ohne Hervorhebung sind etwa gleichmässig verteilt)
 - Grösse
   - sehr gross: Längerfristig wachsend. Kein maximales Ausmass/Abschluss abschätzbar
   - gross: Hoher Aufwand zu erwarten. Ausmass gegenwärtig abschätzbar.
   - mittel: Projekt mit überschaubarem Aufwand und Abschluss.
   - wechselnd: Aufwand in überschaubaren, abgeschlossenen Modulen

[^1]: Die Codebase stellt einen beachtlichen Teil des investierten Kapitals eines Unternehmens dar. Jede neue App benutzt Tools. DIe Tools bestehen aus zahlreichen, simplen und wiederverwertbaren Funktionen. Grosse Teile der Tools und der Funktionen werden projekt-übergeordnet abgelegt. Somit sind neue Teile oder komplette Apps mit deutlich vermindertem Aufwand erstell- und wartbar. Üblicherweise sind mehrere Code-Bases notwendig, da diese für verschiedene Zwecke oft nicht verwendbar sind.