Annemarie

@Sebastian Grünewald @HK alias Holger@Marika Karl Die Idee gibt es jetzt auch auf unserem Feature-Ideenboard: https://portal.productboard.com/1zukbs88k3fmynuc66j34p17/c/136-auf-aufgenommenen-fotos-text-platzieren Dieselbe Funktion wäre für den Skizzenbaustein denkbar, könnte aber andere Wichtigkeit oder andere Einsatzszenarien haben, daher ist sie als separate Idee aufgeführt: https://portal.productboard.com/1zukbs88k3fmynuc66j34p17/c/137-auf-skizzen-text-platzieren

Wir teilen wieder ein Update aus der Produktentwicklung mit euch. Hier erfahrt ihr den neusten Stand von unserem Modernisierungsprojekt, das die smapOne Plattform im Hintergrund verbessert. Außerdem lest ihr, was es mit den Änderungen rund um unsere Releases auf sich hat, die ihr vielleicht schon bemerkt habt. Zum Artikel: Ein neues Team für Datensätze und häufigere Updates!

Hi zusammen, helft mir bitte auf die Sprünge: Der Herausgebername ist ja genau das, was dafür da ist, den smap-Nutzer zu informieren, von wem eine smap stammt. Dazu kann in das Feld im Profil durch jeden Creator ein aussagekräftiger Wunsch-Anzeigename eingetragen werden. Der Herausgebername ist damit der Name für sich selbst, den der Creator an seinen smaps stehen haben möchte, oder die Organisation, für die er steht und unter der er seine "Werke" veröffentlichen möchte. @Philip Alvermann Klingt erst einmal wirklich, als wäre es genau das Werkzeug der Wahl für deinen Wunsch, an der smap den herausgebenden Creator ablesen zu können. Kannst du noch einmal näher drauf eingehen, warum das für euch kein gangbarer Weg ist? Jeder Creator müsste natürlich seinen Wunsch-Anzeigenamen im Herausgeberfeld eintragen. Scheitert es speziell am Aufwand zum Befüllen dieses Feldes? Oder ist der Knackpunkt, dass ein Firmenname im Herausgeberfeld bei allen Creatoren einer Firma gleich wäre (keine Unterscheidbarkeit), aber ein Personenname im Herausgeberfeld keine Zuordnung zur Firma herstellen würde? Dafür kann als Herausgebername ja beispielsweise auch eine Kombination aus Personennamen und Firmennamen gewählt werden. So wäre auch bei verschiedenen Creatoren aus einem Unternehmen immer klar, dass es von nicht von verschiedenen Firmen kommt, und sie wären trotzdem unterscheidbar. Was übersehe ich?

@David Susami Danke für die zusätzliche Erklärung und Screenshots, das gibt mir ein klareres Bild! Ich fasse mal zusammen: Es geht in erster Linie um eine Darstellung von Bausteinbeschriftung und -wert nebeneinander statt untereinander. Mehrere aufeinanderfolgende Bausteine innerhalb einer Gruppe sollen zusammen eine Tabelle ergeben, wobei jeder Baustein eine Zeile bildet. Beginnt eine neue Gruppe, so beginnt eine neue Tabelle. Hintergrund dieser Darstellung ist, dass es einfach ansprechender wäre?

Kleines Update: Seit letzter Woche wird nun auch der Codetyp EAN-13 unterstützt, als weit verbreiteter Barcodetyp für Produktkennzeichnungen. Für die Idee, die Größe der Codes beeinflussen zu können, findet ihr jetzt auch ein Kärtchen auf dem Ideenboard. (@Thomas Giesing und @Michael Prem, euren Bedarf an dieser Erweiterung habe ich bereits erfasst, ihr müsst dort also nicht nochmal voten. Aber ihr dürft natürlich, wenn ihr uns auf diesem Weg noch eure eingeschätzte Wichtigkeitskategorie oder weitere Infos mitgeben möchtet - beispielsweise in deinem Fall, Michael, den Hintergrund des Wunschs nach größerer Darstellung: Ich könnte mir vorstellen, bei euch soll aus größerer Entfernung gescannt werden oder Ähnliches....)

Hallo @David Susami, hier bin ich neugierig, wie du es dir im Detail vorstellst: Bei Wiederholungsgruppen haben wir die enthaltenen Bausteine als Spalten, und die wiederholen sich mit jedem Eintrag (Zeile), was eine Tabellendarstellung absolut naheliegend macht. Aber bei einer Gruppe haben wir nur eine Reihe von Bausteinen. Also eine Liste oder Tabellenzeile. Wie viel Sinn hat eine Tabelle mit nur einer Zeile? Oder denke ich in die falsche Richtung? Vielleicht hast du ja auch einen Screenshot für uns, wenn ihr eure Wunschdarstellung für Gruppen schon immer manuell mit selbst erstellten Berichtsvorlagen baut.

Hi @Micha Zenke und @Florian Kirchleitner, danke für eure Ideen! Eine kurze Einordnung, was wir dazu denken: - Datenquellen "bequem" löschen: Ja, soll in Zukunft im Datenquellen-Verwaltungsbereich hinzukommen. Den Wunsch danach haben wir schon vermutet und Anfragen wie diese bestätigen das. - Sehen, in welchen smaps eine Datenquelle verwendet wird: War schon bei der Einführung des Verwaltungsbereichs ein Gedanke, der uns auch kam. Wird auf jeden Fall kommen, wenn wir die Arbeit an den Datenquellen-Betafeatures fortsetzen. - Statt Datenquellen durch Hochladen von Excel-Dateien zu aktualisieren, einen Zugang zu einem Sharepoint-Ordner oder anderen online erreichbaren Ort hinterlegen, und die Datenquelle aktualisiert, sobald sich die dort platzierte Datei ändert: Ja, auch dafür haben wir schon von verschiedenen Seiten Interesse vernommen und auch das möchten wir uns vornehmen, wenn wir uns wieder Datenquellen widmen. Hierzu gibt es sogar ein Kärtchen auf unserem Ideenboard. Wann wir im Bereich Datenquellen wieder die Ärmel hochkrempeln und uns diesen und anderen Veränderungen widmen (und die Beta-Features komplettieren), wird nicht mehr dieses Jahr sein, da wir - ihr habt es vielleicht schon an anderen Stellen gehört - in nächster Zeit noch einen starken Fokus auf unsere neue Web-App und damit einhergehende technologische Verbesserungen legen. Die Themenreihenfolge danach steht jetzt noch nicht fest. Aber wenn es soweit ist, werden eure drei genannten Themen garantiert nicht vergessen werden.

So eine Idee ist hier kürzlich diskutiert worden. Schau gern mal, ob das in die gleiche Richtung geht:

@Sebastian Faßmann @Jeanne Merswolken Danke, das hilft sehr, zu verstehen, wo bei euch die Knackpunkte liegen! Der Wunsch nach mehr Infos, um rauszufinden, ob es einfach in dem Moment an der Internetverbindung scheiterte oder was anderes dahinter steckt, ist nachvollziehbar (gerade, wenn es immer mal Problemchen gibt). Wegen dem Fokus auf Weiterentwicklung der Web-App aktuell werden wir das Thema in nächster Zeit nicht in größerem Umfang angehen. Ich gebe es aber intern weiter zur Prüfung, ob sich beispielsweise im Zuge der Entwicklung an solchen Stellen etwas berücksichtigen lässt. Selbst wenn das vorerst nicht der Fall sein sollte, nehmen wir es als Wunsch und irgendwie ja auch Usabilityproblem mit auf.

Hallo @René Strahl, danke dir für die wertvollen Infos, warum welcher Codetyp interessant sein könnte! Mit EAN-13-Codes, die wir als nächstes ergänzen wollen, wäre euch in dem Fall dann nicht geholfen wegen der größeren Zeichenlänge, die ihr benötigt. Dafür sind solche Werte generell aber schon mal mit den QR-Codes abgedeckt, dann nur eben kein eindimensionaler Strichcode... Fürs Bewerten, welche Codetypen wir noch hinzufügen sollten, sind uns in allererster Linie zwei Fragen wichtig: - Können die Werte, die ihr benutzt, in einem vorhandenen Codetyp codiert werden? (Hier verstehe ich in eurem Fall: Ja.) - Können eure Scanner diese Codetypen scannen? (Hier bin ich nicht sicher, was euren Fall betrifft: Können eure Scanner dann tatsächlich keine QR-Codes scannen?) Wenn beides mit ja beantwortet werden kann, solltet ihr grundsätzlich erst einmal Nutzen aus dem Feature ziehen können. Auch wenn es dann natürlich noch weiterführende Gründe geben kann, sich andere Typen zu wünschen. Dazu eine Rückfrage: Weiter oben wurde die Idee aufgebracht, die Größe der Codes zu beeinflussen. Gingen QR-Codes kleiner und würden dadurch eher "in der Zeile bleiben", würde euch das ein Stück weiterbringen für die Ausgabe im Bericht? Was die weiteren Codetypen angeht, behalte ich deine Infos auf jeden Fall auf dem Schirm für potenzielle Erweiterungen und werde zunächst weiter beobachten, was für Bedarf sich in diesem Bereich noch weiter auftut. Vielleicht lassen sich verschiedene Dinge mit passenden Lösungen vereinbaren, damit unser Codekatalog überschaubar bleibt.

@Jeanne Merswolken Datenübertragung könnte erst einmal alles sein, sogar die Übertragung von Inhalten von unseren Servern zu eurem Browser oder der App zur Anzeige. Das Abrufen von erhaltenen Aufgaben, Durchführen von smap-Updates, Abrufen von Berichten, Aktualisierung der smap-Vorschau, ... Aber in diesem Fall ist schon das Absenden von Datensätzen gemeint, schließe ich aus deiner Frage. Und was ist das Verhalten, das ihr da beobachtet? Bekommt ihr fehlgeschlagene Datensätze? Bleiben die Datensätze in "Ausstehend" liegen? Ich frage, um den Fall einzugrenzen, über den wir hier sprechen, und die Stelle, wo ihr euch mehr Infos wünschen würdet.

Hi @Jeanne Merswolken, zum besseren Verständnis würde ich gerne wissen: Geht es dir um die Übertragung (=Absenden / Weiterleiten) von Datensätzen, oder um andere Stellen? Und wisst ihr schon mehr über die verschiedenen Gründe der Probleme?

@René Strahl Moin René, ja, aktuell sind nur QR-Codes möglich, die ja sowohl für das Codieren von Texten als auch von Nummern verwendet werden können. Aufgrund von Feedback, dass in bestimmten Fällen verwendete Scanner nur normale Barcodes unterstützen, denken wir daran, zusätzlich noch EAN-Codes zu ermöglichen. Was führt bei euch dazu, dass Barcodes interessant wären? Und würden euch dafür EAN-13-Codes passen? Spannend finde ich auch, dass du DMC-Codes erwähnst. Vielleicht magst du noch darauf eingehen, was diese mitbringen, das ihr braucht und QR-Codes nicht haben? Übrigens: An die Variante über die Feldfunktionen von Word haben wir zu Beginn auch gedacht, haben uns aber für den aktuellen Ansatz entschieden, nachdem wir bei dem Umsetzungsweg auf größeren Hürden gestoßen sind.

@Thomas Giesing Verstehe, ideal wäre also, ihn etwas kleiner zu machen. Es ist eine denkbare Erweiterung, dass die Größe der Codes auch beeinflusst werden könnte. Ich vermerke mir euren Wunsch als Erweiterungsidee schon einmal intern, möchte aber erst einmal weiter schauen, wie groß der Bedarf insgesamt danach ist und was wir noch so für Feedback zu der neuen Funktion bekommen. Für den Moment frage ich dich aber gern noch ein bisschen weiter aus zu deiner Einschätzung, und werde das berücksichtigen, wenn wir die Erweiterung tatsächlich angehen sollten: Die minimal empfohlene Größe für QR-Codes ist 1x1 cm. Wäre euch damit geholfen? Ein kleinerer Code würde, um gut scannbar zu bleiben, kürzere erlaubte Zeichenketten bedeuten. Für euch akzeptabel oder no go? Wenn wir keine freie Größeneinstellung, sondern nur Stufen (z.B. groß, mittel, klein) anbieten würden, wäre euer Bedarf erfüllt? Danke fürs Zeitnehmen!

@Thomas Giesing Aktuell nein, der Code wird immer in gleicher Größe ausgegeben. Bei euch gäbe es wohl Bedarf dazu? Magst du das näher umreißen?